What is garbage

ReferenceCounter ReferenceCounter

An algorithm used to identify what is garbage. If an object is referenced, it is a useful object. If it is not referenced, it is garbageAs shown in the figure above, several objects are referenced in a loop, and RC has a count, but all three as a whole are actually garbage.

GC Roots reachable algorithm

In general, GC Roots include (but are not limited to) the following:

  1. Local variables in Java method frames;
  2. Static variables that have been loaded;
  3. JNI Handles;
  4. Threads that have been started but not stopped;

Start from the roots. Everything you go is useful. Everything you can’t go to is garbage.

Three ways to recycle garbage

Mark sweep – Low fragmentation efficiency due to location discontinuities (two sweeps)

Copy Copy – No fragmentation, wasted space, Pointers need to be adjusted

Mark Compact – No fragmentation, low efficiency (two scans, pointer adjustment required)

JAVA memory generation model

The model used by part of the garbage collector

  1. Epsilon ZGC Shenandoah is neither a logical nor a physical generation
  2. G1 logical generation, not physical generation
  3. Young: Serial, ParallelScavenge ParNew Old: SerialOld, ParallelOld, CMS above a generational garbage collector is logic and physical generational

New Generation + Old age + Permanent Generation (1.7) Perm Generation/ metadata area (1.8) Metaspace

  1. Permanent metadata – Class
  2. Permanent generation must specify a size limit, metadata can be set or not set, no upper limit (limited by physical memory)
  3. String constants 1.7 – permanent generation, 1.8 – heap
  4. MethodArea Logical concepts – persistent generation, metadata

New generation = Eden + 2 survivor zones

  1. After YGC is collected, most of the objects are collected and enter S0 alive
  2. Again YGC, the living object Eden + s0 -> s1
  3. YGC again, Eden + S1 -> S0
  4. Age enough -> old age (general 15 CMS 6 note Max 15)
  5. It won’t fit in section S -> Old age

The old s

  1. diehard
  2. The old age is FGC Full GC

GC Tuning (Generation)

  1. Minimize FGC
  2. MinorGC = YGC
  3. MajorGC = FGC

The dynamic allocation of objects

TLAB:JVM creates a small thread-local Allocation Buffer (TLAB) in the Eden Space of the new generation of memory. The default is 1% of Eden Space. Many objects in Java programs are small, throwaway objects that do not have thread sharing and are suitable for fast GC, so the JVM usually prioritises allocation on TLAB for small objects, and allocation on TLAB has no lock overhead because it is thread private. Therefore, in practice it is usually more efficient to allocate multiple small objects than to allocate one large object. In other words, each Thread in Java has its own buffer called TLAB (Thread-local Allocation Buffer). Each TLAB can be operated by only one Thread. TLAB can be combined with bump-the-Pointer technology to achieve fast object allocation. There is no need for any lock synchronization, that is, the object allocation does not lock the whole heap, but only allocates in its own buffer.

Dynamic age

The virtual machine does not always require that the object’s age must reach MaxTenuringThreshold to be promoted to the old age. If the sum of the size of all objects of the same age in the Survivor space is greater than half of the size in the Survivor space, objects older than or equal to this age can directly enter the old age. There is no need to wait until the age required in MaxTenuringThreshold.

Distribution of guarantee

During YGC, survivor zone space is not enough to guarantee space directly into the old era

Common garbage collector

  1. Serial was introduced in the JDK to improve efficiency, and PN was created to match CMS, which was introduced late in version 1.4. CMS is a landmark GC that started the process of concurrent collection, but CMS has many bugs. So any current JDK version defaults to CMS concurrent garbage collection because you can’t stand STW
  2. Serial Young generation Serial reclamation
  3. PS young generation parallel collection
  4. ParNew young generation with concurrent collection of CMS
  5. SerialOld
  6. ParallelOld
  7. In the old days, ConcurrentMarkSweep was concurrent, garbage collection and application were running at the same time, reducing STW time (200ms). There were many CMS problems, so now no version is CMS by default, you have to manually specify CMS. Since it is MarkSweep, there will definitely be fragmentation problems. When the fragmentation reaches a point where the old age allocation object of CMS cannot be allocated, use SerialOld to recycle the old age. Imagine: PS + PO -> add memory for garbage collector -> PN + CMS + SerialOld (a few hours – a few days of STW) dozens of G of memory, single thread recycling -> G1 + FGC dozens of G -> T memory server ZGC algorithm: Three-color tag + Incremental Update
  8. G1(10ms) algorithm: tricolour + SATB
  9. ZGC (1ms) PK C++ : ColoredPointers + LoadBarrier
  10. Shenandoah algorithm: ColoredPointers + WriteBarrier
  11. Eplison
  12. 1.8 Default garbage collection: PS + ParallelOld

Common garbage collector combination parameter Settings :(1.8)

  • -XX:+UseSerialGC = Serial New (DefNew) + Serial Old

  • Small programs. This is not the default option, and HotSpot automatically selects the collector based on calculation and configuration and JDK version

  • -xx :+UseParNewGC = ParNew + SerialOld This combination is rarely used (deprecated in some versions)

  • Stackoverflow.com/questions/3…

  • -XX:+UseConc(urrent)MarkSweepGC = ParNew + CMS + Serial Old

  • -xx :+UseParallelGC = elinsane + elinsane (1.8 default)

  • -XX:+UseParallelOldGC = Parallel Scavenge + Parallel Old

  • -XX:+UseG1GC = G1

  • Linux does not find a way to view the default GC, while Windows prints UseParallelGC

  • java +XX:+PrintCommandLineFlags -version

  • Tell by GC logs

  • What is the default garbage collector for Linux 1.8?

  • 1.8.0_181 默认（看不出来）Copy MarkCompact

  • 1.8.0_222 Default PS + PO