某次gc频繁

使用jmap -dump得到文件，mat分析，大量Finalizer对象占据了主要空间。Finalizer对象是实现了finalize()方法的f类，生成实例时一对一生成后，挂在Finalizer类的静态队列（一个gcRoot）下的。它可以保证在一次gc后，如果Finalizer对象对应的f类只有Finalizer引用（被静态队列引用，无法销毁），就把该Finalizer对象从static队列移除，并调用f类对象的finalize方法。此后该f类对象就没有引用了，可被gc。
此次Finalizer对象中大多包含的是SocksSocketImpl对象，经查证该类是网络通信常用类，其父类复写了finalizer()方法，执行close()。
用户大量新建局部的SocksSocketImpl对象，导致生成大量Finalizer对象引用了s对象。局部s对象的用户引用被很快释放，但是由于有Finalizer对象引用，在下一次gc时，会把这些Finalizer对象置入queue中等待清理（从F链表中remove），清理后s对象、Finalizer对象才真的没有引用，可以等待回收。用户不及时close()会导致Finalizer对象的清理速度较慢，增加SocksSocketImpl和Finalizer的回收难度。
有经验表明用户及时close()会优化大量Finalizer在链表中堆积的问题。（这里有疑问，用户不close()，是会导致一直持有吗？还是说会导致Finalizer阻塞？因为有经验表明用户及时close()会优化大量Finalizer堆积的问题）待排查。
http://www.infoq.com/cn/articles/jvm-source-code-analysis-finalreference
此次排查似乎不是S对象的原因。