反正浪费你的时间也是在浪费工司的钱

VM, 传给java的
如果你放在program arguments里， 就可以解释为什么会卡在2.3G了， jvm deault heap size 是2048m, jvm在 GC ， 在3 次full GC,释放不了2%内存的话就会throw out of memory exception: excessive GC time

还有，你用的内存都是在heap里，所以不需要设 PermSize , default size 32M or 96M based on 32bit or 64 bit is big enough

跑的时候在java opts里加个 -Xrunhprof:cpu=samples,interval=10,depth=8
程序停掉的时候目录下会多一个"java.hprof.txt"， 看那里面profiler 显示哪个function 用的时间多。 这个是发现问题最容易和方法。 hprof是java 自带的profiler

见 http://java-performance.info/primitive-types-collections-trove-library/

@buptlee 应该没什么问题， 像 @lehui99 说的在HashMap初始化时指定initCap 应该可以解决这个问题。
建议是，如果你对内存使用在意的话，可以使用别的一些数据类型（Gnu Trove 里的TIntObjectHashMap, TIntArrayList etc. ）在几乎不损失性能的同时把总内存降低到2G ~ 3G

cpu使用率后来达到了100% 应该是在rehash

楼主对内存的估算不太正确， 没有算进去java object , 和HashMap 的overhead.
一个空object 会用16 bytes, Node 里有两个int, 也就是一个Node 会在Heap里用掉32 bytes
一个空LinkedList里应该有4个private fields 会占用 (4+2) * 8 = 48 bytes
一个LinkedList用的memroy 是 48 + 24* size_of_list , 你的size 是50 , 也就是 1248 bytes

HashMap 的内存占用是 32 * SIZE + 4 * CAPACITY bytes , 你的size 是 120,000,000 / 50 . default load factor 是0.75， capacity 就是 (120,000,000 / 50) / 0.75.

估算一下， 一共会用7个多G 的内存。

另外hashmap rehash 是很快的，这个数据量不是很大， cpu没有吃满应该是别的原因，比如disk io, 看一下你top 里的 wa 是多少。

楼主也可以把代码贴出来给大家看看，分析一下。

可以试试tunna proxy, 把ssh 的流量伪装成http

@SoloCompany 谢谢，　现在才知道　Lightweight process

@SoloCompany 非常确定

aria2 ?

我觉得Minila Air 最大的问题是右Shift 位置不在标准位置上，　我用了一个月才适应，　回到Mac 键盘上又按不对键了

@zhangyuting 可以，异步的

celery, 不知道是不是大材小用了

找ex-examiner 给改作文

既然是mask那么所有subprocess生成的文件都要经过parent process 的mask, 你可以用chmod 去改啊

我用cron tab + beautifulsoup(python) 存成csv
需要执行javascript的话用casperJS