我利用socket.io库做一个视屏弹幕的后台服务 node开启了手动回收内存（–expose-gc）
在我利用脚本做压力测试事，模拟1000个客户端，所有客户端在一个for循环发1个消息。 此时服务端内存增加很快，在断开连接后，内存没有下降。
你之前是写C的？ 每次看到这些个sockeio连接断开，内存不释放问题，我就想问下，你知道node的gc机制吗？你线上服务也能手动gc？既然让v8去做gc管理，就不要苛刻他的回收。建立socke连接本来就是一个耗内存的操作，你断开后连接后基于正常的惰性回收机制，不会立即回收，确切说是不可能立即回收，只有等到你再次到达那个阀值或者超过那个阀值，才会触发全面的gc，否则小gc不会有太大的内存波动。抛开这个问题不谈，问一个问题的时候，node的gc机制大概了解下也不会问出这样的问题；
@haozxuan 我去年刚毕业，是学C的 node的垃圾回收机制，我只是通过朴灵的《深入浅出NODEjs》有点了解 我利用定时器调用gc(),手动的回收内存。 我在建立1000个连接单不发送消息，断开连接后内存会回收 但是建立连接后发送消息后，内存会回收一部分，但不能全部回收
@rongwj 抱歉，早上可能语气有些冲；其实node的gc机制是“不可控”的，他并不像c或者其他语言，申请一个变量，完了就结束释放掉，如果仔细研究他的垃圾回收机制的话，你会发现，他主要使用分代式回收机制，新生代内存使用完毕后会立即释放，但是对于老生代内存由于存储的对象不适合大规模的回收，所以只有等到新生代对象晋升到老生代内存不够的情况下，才会触发回收老生代内存，举个栗子，假如新生代比老生代为2：4，此时新生代实际有2份，老生代里面已经存储了3份，假如有2份的新生代晋升到老生代时，发现2+3>4，溢出了老生代内存限制，这个时候才会触发老生代的gc，也就是所谓的惰性回收机制，你可以通过process.memoryUsage()看到，虽然RSS很大，但是实际used会很小；
gc这个问题，你可以试着不断进行连接来测试，就是，连接1000个，断开，再连接一千个，断开，这样不断循环，理论上就可以获得一个稳定的内存占用。。。如果不是的话，看看是不是用了全局变量数组来存放东西，另外测试时可以考虑用ulimit进行限制，缩短测试时间
另外，用定时器调用gc是错误的，会导致性能问题，因为你不能保证你调用的时间刚好不在处理请求，虽说gc只是建议回收内存，但是在一些情况下仍会造成线程被挂起一段时间，gc的用法应该在明确的知道马上会进行大量内存分配的时候(并且不想被中途打断)，辅助v8选择合适的时机进行垃圾收集，其实一般情况下这个函数作用有限，滥用后果却比较负面，相比之下，v8自己的机制在大多数情况下还是比代码层面的优化好很多
来自酷炫的 CNodeMD
