Minor GC vs Major GC
Fast recall
Quick revision
Core answer
Knowledge of the generational GC model and practical implications for performance monitoring
Treating minor, major, mixed, and full as JVM-wide event contracts instead of collector-specific monitoring terms
Use the actual collector and unified log event, then compare pause, reclaimed bytes, allocation, promotion, live-set trend, and application latency
Interview-ready guide
Interview answer
Minor and major GC are common log terms, but they are not one portable JVM contract.
With a generational collector, a young or minor event mainly targets young regions. Broader work may be called old, mixed, major, or full depending on the collector, and some phases can run concurrently with the application.
For example, a G1 young evacuation and a G1 mixed collection have different scopes even though both can appear as young pauses in unified logs. That means I would not quote a fixed pause time or call a certain event count healthy without context. I would read the collector name and event cause, then compare pause time, reclaimed memory, allocation rate, promotion, old-region occupancy, and application latency.
A frequent broad collection can suggest memory pressure, but it does not prove a leak by itself.
Minor GC vs Major GC
Direct Answer
Minor, major, and full GC are monitoring terms rather than one JVM-wide contract, and collectors use them differently. In a generational collector, a young or minor collection targets the young generation; an old, mixed, or full collection has a broader scope. Do not assume fixed frequency or pause time—read that collector's event names, heap-region data, and pause metrics.
Code Example
// Run with a chosen JDK and collector, then inspect its actual event names:
// java -Xlog:gc* -Xmx64m AllocationDemo
public class AllocationDemo {
static volatile int sink;
public static void main(String[] args) {
for (int i = 0; i < 2_000; i++) {
byte[] temporary = new byte[1024 * 1024];
sink ^= temporary[0];
}
}
}
This creates allocation pressure for observation; it does not guarantee which events occur. Collector, heap layout, JVM version, JIT optimization, and flags determine the log. Read the event cause and region data instead of assigning every event a fixed cost.
Common Mistakes & Pitfalls
- Equating Major with Full GC: Neither term has one portable scope, and class unloading or metaspace work is not defined by a simple major/full rule.
- Judging from frequency alone: A frequent event with tiny total cost may be harmless; a rare event can still violate a tail-latency objective. Use pause percentiles, CPU, reclaimed memory, and application impact.
- Calling every young collection cheap: Young events are often efficient, but evacuation failure, a large live set, allocation bursts, or limited CPU can change the result. Measure the selected collector.
Check your understanding
Answer these without looking back at the article.
- What causes objects to be promoted from Young to Old Generation prematurely?
- How do you monitor GC activity in a Java application?
Looking for a structured roadmap?
Every module on this page is also part of the full Java backend interview track.