JVM default boot parameters, DisableExplicitGC to false, ExplicitGCInvokesConcurrent to false, for the majority of GC (in addition to other GC ZGC, including the CMS, G1, Shenandoah GC, etc.), are FullGC, and are synchronous GC, the underlying principle will be analyzed in another article, let’s first clarify why such an interface.

1. Frameworks that use and manage out-of-heap memory require Full GC mechanisms to trigger out-of-heap memory collection

JVM Native Memory Tracking: Native Memory Tracking

Native Memory Tracking: Total: reserved=6308603KB, committed=4822083KB - Java Heap (reserved=4194304KB, committed=4194304KB) (mmap: reserved=4194304KB, committed=4194304KB) - Class (reserved=1161041KB, committed=126673KB) (classes #21662) ( instance classes #20542, array classes #1120) (malloc=3921KB #64030) (mmap: reserved=1157120KB, committed=122752KB) ( Metadata: ) ( reserved=108544KB, Committed =107520KB) (used=105411KB) (free=2109KB) (waste=0KB =0.00%) (Class space:) (reserved=1048576KB, Committed =15232KB) (used=13918KB) (Free =1314KB) (waste=0KB =0.00%) - Thread (reserved=355251KB, committed=86023KB) (thread #673) (stack: reserved=353372KB, committed=84144KB) (malloc=1090KB #4039) (arena=789KB #1344) - Code (reserved=252395KB, committed=69471KB) (malloc=4707KB #17917) (mmap: reserved=247688KB, committed=64764KB) - GC (reserved=199635KB, committed=199635KB) (malloc=11079KB #29639) (mmap: reserved=188556KB, committed=188556KB) - Compiler (reserved=2605KB, committed=2605KB) (malloc=2474KB #2357) (arena=131KB #5) - Internal (reserved=3643KB, committed=3643KB) (malloc=3611KB #8683) (mmap: reserved=32KB, committed=32KB) - Other (reserved=67891KB, committed=67891KB) (malloc=67891KB #2859) - Symbol (reserved=26220KB, committed=26220KB) (malloc=22664KB #292684) (arena=3556KB #1) - Native Memory Tracking (reserved=7616KB, committed=7616KB) (malloc=585KB #8238) (tracking overhead=7031KB) - Arena Chunk (reserved=10911KB, committed=10911KB) (malloc=10911KB) - Tracing (reserved=25937KB, committed=25937KB) (malloc=25937KB #8666) - Logging (reserved=5KB, committed=5KB) (malloc=5KB #196) - Arguments (reserved=18KB, committed=18KB) (malloc=18KB #486) - Module (reserved=532KB, committed=532KB) (malloc=532KB #3579) - Synchronizer (reserved=591KB, committed=591KB) (malloc=591KB #4777) - Safepoint (reserved=8KB, committed=8KB) (mmap: reserved=8KB, committed=8KB)Copy the code
  • Java Heap: Heap memory, i.e-XmxLimit the maximum heap size of memory.
  • Metaspace: metadata that contains information about classes and methods to be loaded-XX:MaxMetaspaceSizeLimit the maximum size, the other is class space, by-XX:CompressedClassSpaceSizeLimit maximum size
  • Thread: Thread and Thread stack occupy memory, the size of each Thread stack-XssLimit, but there is no limit to the total size.
  • Code: JIT just-in-time compiled (C1 C2 compiler optimized) Code takes up memory, subject to-XX:ReservedCodeCacheSizelimit
  • GC: Garbage collection takes up memory, such as CardTable, tag count, partition records, tag GC Root, etc. It’s not restricted, it’s usually not very big.
  • The memory used by the C2 Compiler’s own code and markup is not limited and is generally not very large
  • Internal: The amount of memory used by JVMTI for command line parsing. This is unlimited and generally not very large
  • Symbol: Size occupied by the string constant pool-XX:StringTableSizeNumber limit, total memory size is not limited
  • Native Memory Tracking: The size of the Memory used by the acquisition itself, if not enabled, will not be used, this is not limited, generally not very large
  • Arena Chunk: All memory allocated via Arena. This is unlimited and usually not very large
  • Tracing: Memory occupied by all collections. If JFR is enabled, it is mainly the memory occupied by JFR. It’s not restricted, it’s usually not very big
  • Logging, Arguments, Module, Synchronizer, Safepoint, and Other are things we don’t care about.

There are two types of Memory Native Memory Tracking that are not recorded:

  • Direct Buffer: Indicates the Direct memory
  • MMap Buffer: memory used to map files

In addition to heap memory, other memory, some also need GC. For example: MetaSpace, CodeCache, Direct Buffer, MMap Buffer, etc. Early JVMS prior to Java 8 had an imperfect mechanism for these memory reclamation, and in many cases FullGC was required to scan the entire heap to determine which of these areas of memory could be reclaimed.

There are frameworks that make extensive use of and manage this off-heap space. For example, Netty uses Direct Buffer, Kafka and RocketMQ use Direct Buffer and MMap Buffer. They all apply for a piece of memory from the system in advance, and then manage it and use it. When the space is insufficient, continue to apply to the system, and there will be capacity reduction. For example, netty tries to add unreachable Reference objects to the Reference list after the Direct Buffer reaches the limit of -xx :MaxDirectMemorySize. The internal daemons that depend on Reference trigger Cleaner run() methods that can be recycled for DirectByteBuffer associations. If the memory is insufficient, the execution System., expected to trigger a full gc, gc () to recycle DirectByteBuffer objects in the heap memory to trigger the heap memory recovery, if still more than limit, it throws Java. Lang. OutOfMemoryError.

2. When WeakReference and SoftReference are used, GC recovery is required.

For WeakReference, whenever GC occurs, either Young GC or FullGC will be reclaimed. SoftReference is reclaimed only in FullGC. When our program wants to actively reclaim these references, we need methods that trigger a GC, which we use system.gc ().

3. Testing, learning JVM mechanics

Sometimes, to test and learn something about the JVM, we need to start the JVM after doing a GC, which also uses system.gc ().

Wechat search “my programming meow” public account, a daily brush, easy to improve skills, won a variety of offers