Why it matters
Every HBase user eventually encounters GC-driven latency spikes. Understanding what causes them and how to tune them is the difference between random configuration guessing and confident production operation. It is also the single most impactful configuration area.
GC tuning also determines how large a RegionServer heap can practically be. Larger heaps enable larger block caches and larger memstores, but only if GC pauses stay tolerable. G1GC and off-heap options are what unlock large heaps in practice.
The architecture
The RegionServer JVM heap holds several major consumers. The block cache (when on-heap) holds recently-read HFile blocks. The memstore (when on-heap) holds pending writes. RPC handler thread buffers, HFile index cache, and various internal structures make up the rest.
Objects allocated in the heap first live in the young generation. Objects that survive many collections are promoted to the old generation. GC works differently on each: young generation collection is fast (minor GC); old generation collection is slower (major GC or mixed collections in G1).
How it works end to end
G1GC is the default and recommended collector for HBase. It divides the heap into many regions and collects them incrementally, prioritizing regions with the most garbage. Pause targets are configurable via -XX:MaxGCPauseMillis; typical values are 100 to 200 milliseconds.
Heap sizing follows a rule of thumb: use 16 to 32 GB per RegionServer. Larger heaps produce longer pauses even with G1GC. Smaller heaps constrain block cache and memstore.
Off-heap escapes are the answer for larger caches. BucketCache moves block cache off-heap to arbitrarily large sizes. Off-heap memstore (still experimental in some versions) does the same for memstore. Both bypass GC entirely for that memory.