1. many NIO frameworks, such as netty, have a lot of memory-mapped code (memory map), while mmap memory is not allocated in the Eden or old Zone. It is out-of-heap allocation, therefore, these frameworks call system manually. gc to reclaim the space allocated by mmap. (System. gc triggers full gc. The memory allocated by mmap is reclaimed only when full gc is used ).
2. Because the NIO framework frequently calls full gc, it will seriously affect the performance. Therefore, someone has added this parameter-XX: + DisableExplicitGC to disable system. gc from triggering gc. After system. gc () is added, gc is not triggered.
3. However, if gc cannot be called manually,
* NIO or NIO framework (Mina/Netty) is used)
* The DirectByteBuffer is used to allocate the byte buffer.
* Memory ing using MappedByteBuffer
In the above cases, off-heap memory cannot be recycled. Therefore, we mentioned replacing DisableExplicitGC with the ExplicitGCInvokesConcurrent parameter (this relationship has left me wondering for a long time, why should we replace DisableExplicitGC with the explicitgc parameter, I have made some comments on the Internet, but no one can clearly explain why! This is the most important). Of course, this parameter must be used only when CMS is used for full GC.
However, at this point, I still don't know the benefits of ExplicitGCInvokesConcurrent. Why can I replace DisableExplicitGC? After searching, I found this article:
Http://breezylee.iteye.com/blog/2043056
There is a saying:
3.-XX: + ExplicitGCInvokesConcurrent or-XX: + ExplicitGCInvokesConcurrentAndUnloadsClasses
C ++ code
Like the-XX: + DisableExplicitGC in the first example above, these two parameters are also used to change the System. the default gc () behavior is used. The difference is that these two parameters can only be used with CMS (-XX: + UseConcMarkSweepGC), and System. gc () will still trigger GC, but not trigger a full GC of full stop-the-world, but a concurrent GC cycle (liuinsect note: one concurrent cycle is actually one gc in CMS. CMS can only be used in full gc, so it is only a full gc with high efficiency ).
Reference processing is also performed in the cms gc cycle. Therefore, if one of these two parameters is used instead of-XX: + DisableExplicitGC, the long GC pause brought by full GC is avoided, at the same time, NIO direct memory's OOM is not that easy to happen.
Conclusion: at this point, we can understand at least two problems:
1. The origin of ExplicitGCInvokesConcurrent usage.
2. ExplicitGCInvokesConcurrent: in fact, it triggers full gc, but it is more efficient in CMS in full gc.
Articles are messy and need to be discussed. Despite leaving a message, we hope to make common progress.
