我一直在努力解决这个问题,根据我所能找到的所有信息,似乎确实存在一些风险。根据@millimoose在您原帖中的评论以及https://bugs.openjdk.java.net/browse/JDK-6200079,如果正在使用NIO直接缓冲区,则设置-XX:+ DisableExplicitGC可能是一个坏主意。看起来它们正在我们使用的Websphere 8.5应用程序服务器的内部实现中使用。以下是我在调试过程中能够捕获的堆栈跟踪:
3XMTHREADINFO "WebContainer : 25" J9VMThread:0x0000000006FC5D00, j9thread_t:0x00007F60E41753E0, java/lang/Thread:0x000000060B735590, state:R, prio=5
3XMJAVALTHREAD (java/lang/Thread getId:0xFE, isDaemon:true)
3XMTHREADINFO1 (native thread ID:0x1039, native priority:0x5, native policy:UNKNOWN)
3XMTHREADINFO2 (native stack address range from:0x00007F6067621000, to:0x00007F6067662000, size:0x41000)
3XMCPUTIME CPU usage total: 80.222215853 secs
3XMHEAPALLOC Heap bytes allocated since last GC cycle=1594568 (0x1854C8)
3XMTHREADINFO3 Java callstack:
4XESTACKTRACE at java/lang/System.gc(System.java:329)
4XESTACKTRACE at java/nio/Bits.syncReserveMemory(Bits.java:721)
5XESTACKTRACE (entered lock: java/nio/Bits@0x000000060000B690, entry count: 1)
4XESTACKTRACE at java/nio/Bits.reserveMemory(Bits.java:766(Compiled Code))
4XESTACKTRACE at java/nio/DirectByteBuffer.<init>(DirectByteBuffer.java:123(Compiled Code))
4XESTACKTRACE at java/nio/ByteBuffer.allocateDirect(ByteBuffer.java:306(Compiled Code))
4XESTACKTRACE at com/ibm/ws/buffermgmt/impl/WsByteBufferPoolManagerImpl.allocateBufferDirect(WsByteBufferPoolManagerImpl.java:706(Compiled Code))
4XESTACKTRACE at com/ibm/ws/buffermgmt/impl/WsByteBufferPoolManagerImpl.allocateCommon(WsByteBufferPoolManagerImpl.java:612(Compiled Code))
4XESTACKTRACE at com/ibm/ws/buffermgmt/impl/WsByteBufferPoolManagerImpl.allocateDirect(WsByteBufferPoolManagerImpl.java:527(Compiled Code))
4XESTACKTRACE at com/ibm/io/async/ResultHandler.runEventProcessingLoop(ResultHandler.java:507(Compiled Code))
4XESTACKTRACE at com/ibm/io/async/ResultHandler$2.run(ResultHandler.java:905(Compiled Code))
4XESTACKTRACE at com/ibm/ws/util/ThreadPool$Worker.run(ThreadPool.java:1864(Compiled Code))
3XMTHREADINFO3 Native callstack:
4XENATIVESTACK (0x00007F61083DD122 [libj9prt26.so+0x13122])
4XENATIVESTACK (0x00007F61083EA79F [libj9prt26.so+0x2079f])
....
设置-XX:+DisableExplicitGC时,当使用NIO直接字节缓冲区时的全部影响还不是很清楚(这会引入内存泄漏吗?),但至少存在一些风险。如果您使用的应用程序服务器不是Websphere,则可能需要验证应用程序服务器本身是否通过NIO调用System.gc(),然后再禁用它。我有一个相关问题,希望能够在此处对NIO库的确切影响进行澄清:
设置-XX:+DisableExplicitGC时,当使用NIO直接缓冲区时的影响
顺便说一下,Websphere似乎在启动过程中手动调用System.gc()多次,通常在应用程序服务器启动后的前几秒钟内两次,在第1-2分钟内第三次(可能在部署应用程序时)。在我们的情况下,这就是为什么我们首先开始调查的原因,因为所有System.gc()调用都是直接来自应用程序服务器,从未来自我们的应用程序代码。
还应该注意的是,除了NIO库之外,JDK内部实现的RMI分布式垃圾收集也调用System.gc():
由于远程方法调用而导致无法解释的System.gc()调用 核心API的System.gc()调用
至于启用-XX:+DisableExplicitGC是否也会对RMI DGC造成破坏,这也不太清楚。我能找到的唯一涉及此问题的参考资料是上面提到的第一个参考资料,其中指出:
“然而,在大多数情况下,定期进行GC活动就足以实现有效的DGC。”
这个“在大多数情况下”的限定词听起来很含糊,因此,如果可能的话,最好修复代码中的调用,并仅在最后一步完全关闭它们。
System.gc
本身没有任何保证,因此从技术上讲,您不会破坏任何东西,但可能会触发一些已经存在问题的代码中的bug。然而,这并没有什么安慰作用。 - Marko TopolnikSystem.gc()
:) - matt b