Java Garbage Collection Schedule: When the JVM Picks Up Memory, Which Collector to Use and How to Tune It
Java garbage collection has no fixed “pickup day” like a city trash calendar. The JVM collects unused objects when heap pressure, allocation rate, generational thresholds, collector policy and runtime signals say it is needed. Use this guide to understand how Java GC is scheduled, how G1, ZGC, Parallel, Serial and Shenandoah differ, how to read GC logs, and how to choose safe JVM flags for production apps.
Quick Answer: What Is the Java Garbage Collection Schedule?
Java garbage collection is scheduled by the JVM, not by a daily or weekly calendar. The JVM tracks object allocation, heap occupancy, young-generation pressure, old-generation pressure and collector goals. When memory needs cleanup, a GC cycle runs. Some cycles pause application threads briefly; modern collectors such as G1 and ZGC do more work concurrently to reduce long pauses.
📅 Which Week Am I On? — Garbage or Recycling?
160+ Canadian cities · CSS animated bins · Monthly calendar · Holiday warnings
City not in our database yet
We don't have a reference date for this city. To find your biweekly schedule, use one of these options:
Once you have the date of your last garbage week, enter it in the date field above and click Check.
Next pickup date
Based on your collection day
🔑 Bookmark this page to check your schedule every 2 weeks
GC is demand-driven
Java collects memory when objects are no longer reachable and the JVM decides a collection is needed. You do not normally schedule it by time.
Do not rely on System.gc()
Calling System.gc() is only a request. The JVM may ignore it, delay it, or perform a collection depending on flags and collector behavior.
Enable logs and measure
Before changing flags, enable GC logs or Java Flight Recorder. Tune from evidence, not from guesswork or copied internet flags.
Java GC is like an automated pickup service inside the JVM heap. It watches memory neighborhoods, finds unreachable objects, frees space, and may compact memory. The schedule depends on allocation speed, heap size, live object size, collector choice and pause-time goals.
Java Garbage Collection Pickup Day: Why There Is No Fixed Calendar
Searchers often ask for a Java garbage collection “schedule” because they want to know exactly when cleanup happens. In real JVMs, the answer is adaptive.
New objects fill young memory
Most objects are created in the young generation or young regions. When this area fills, a young GC usually runs.
Long-lived objects move old
Objects that survive enough collections can be promoted or retained in older regions. Old-space pressure can trigger larger cycles.
Collector goals matter
G1, ZGC, Parallel, Serial and Shenandoah make different trade-offs between throughput, pauses, CPU usage and heap behavior.
Full GC is a warning
Frequent Full GC often means heap pressure, allocation spikes, memory leaks, fragmentation, bad sizing or a wrong collector for the workload.
How Java Garbage Collection Works: Reachability, Generations and Heap Pressure
Java does not free objects the moment a variable goes out of scope. The JVM checks whether objects are reachable from roots such as thread stacks, static fields, JNI references and internal JVM structures. If an object cannot be reached, it is eligible for collection.
Not reachable means collectible
An object becomes garbage when no live path reaches it. Setting a variable to null can help only when that variable was the last meaningful reference.
Most objects die young
Generational collectors separate young and old objects because many Java objects are short-lived. This lets the JVM collect young memory often and cheaply.
Moving objects reduces fragmentation
Some collectors move live objects to compact memory. Compaction can improve allocation but may require barriers, pauses or concurrent work.
Pauses happen for coordination
Some GC phases require application threads to stop briefly. Low-latency collectors try to keep these pauses short by doing more work concurrently.
GC cannot remove reachable leaks
If a collection, cache, static map, thread local or listener keeps a reference, the object is still reachable. GC will not free it.
Lower pause can cost CPU
Low-latency GC is not free. It can use more CPU or memory headroom because work is shifted into concurrent background phases.
Java Garbage Collectors: G1, ZGC, Parallel, Serial and Shenandoah
The right collector depends on latency target, heap size, CPU budget, deployment model and JDK distribution. Oracle’s current Java GC tuning documentation covers available collectors such as Serial, Parallel, G1 and ZGC. Shenandoah is available in OpenJDK-based distributions that include it, commonly associated with Red Hat and other builds.
Balanced default choice
G1 is a region-based collector designed for multiprocessor machines with larger memory. It aims to balance throughput and pause-time goals with relatively little tuning.
Low-latency, large-heap option
ZGC is designed for very short pauses and scalable heaps. It is useful when latency predictability matters more than maximum raw throughput.
Throughput-focused
Parallel GC can be useful for batch jobs and throughput-heavy workloads where occasional longer pauses are acceptable.
Small apps and tiny heaps
Serial GC is simple and uses a single GC thread. It can fit small command-line tools, small heaps or constrained environments.
Low-pause OpenJDK option
Shenandoah reduces pause times by doing more work concurrently, including compaction. Availability depends on your JDK distribution and platform.
Not a collector choice
Full GC is a type of major cleanup event, not a preferred daily routine. Frequent Full GC means you should investigate memory pressure.
Start with the default collector of your supported JDK unless you have a measured reason to change it. For many server applications, G1 is a strong baseline. For strict latency goals, test ZGC or Shenandoah under real load.
Java GC Commands: Safe Starting Flags for Logs and Collector Tests
Do not copy a long JVM flag list blindly. Start with clear heap sizing, one collector choice, and useful logs. Then run real traffic or a realistic load test.
Java 9+ unified logging
Use this style to capture enough GC information for later review without needing old pre-Java-9 flags.
java -Xms1g -Xmx1g \
-Xlog:gc*,safepoint:file=gc.log:time,uptime,level,tags \
-jar app.jarBalanced server baseline
G1 is often the first collector to test when you want a practical balance of throughput and pause control.
java -Xms2g -Xmx2g \
-XX:+UseG1GC \
-XX:MaxGCPauseMillis=200 \
-Xlog:gc*:file=gc-g1.log:time,level,tags \
-jar app.jarLow-latency test path
Use ZGC when you need very short pauses and can afford the testing, memory headroom and CPU trade-offs.
java -Xms4g -Xmx4g \
-XX:+UseZGC \
-Xlog:gc*:file=gc-zgc.log:time,level,tags \
-jar app.jarBatch throughput path
For offline jobs, ETL, batch processing or non-latency-sensitive workloads, Parallel GC may be worth measuring.
java -Xms2g -Xmx2g \
-XX:+UseParallelGC \
-Xlog:gc*:file=gc-parallel.log:time,level,tags \
-jar batch-job.jarChanging collectors can change latency, CPU, memory footprint, object promotion behavior and failure mode. Test with real allocation patterns, realistic heap sizes, container limits and peak traffic before rollout.
Java GC Tuning Calendar: What to Review Daily, Weekly and Before Releases
Java GC does not run on a calendar, but your operations team can use a review calendar. This is the practical “schedule” that prevents production surprises.
Watch alerts
Track heap usage, GC pause percentiles, allocation rate, CPU, container memory, old-gen trend and OutOfMemoryError alerts.
Review GC logs
Look for increasing pause times, rising old-gen occupancy after GC, promotion failures, Full GC, humongous allocations or sudden allocation spikes.
Load test memory changes
New features can change object allocation, cache size, request payloads, JSON parsing, ORM behavior, thread counts and memory leaks.
Capture evidence
Keep GC logs, heap dumps, thread dumps, JFR recordings and container metrics. Do not restart and lose all evidence unless the service is down.
Review JDK version
JDK releases improve GC behavior over time. Test upgrades carefully, especially when moving between LTS versions or changing container settings.
Revisit heap headroom
Heap headroom is not wasted money if it prevents emergency collections, container kills and latency spikes during peak traffic.
How to Read Java GC Logs Without Getting Lost
GC logs tell the real pickup story. Instead of asking “when does GC run,” ask: how often, how long, why, how much did it reclaim, and what was heap usage after collection?
Healthy signals
- Young GC reclaims memory regularly.
- Old generation is stable after collections.
- Pause times match your service-level goal.
- No frequent Full GC.
- No steady heap climb after each GC.
- Container memory is below the kill threshold.
Danger signals
- Frequent Full GC events.
- Old-gen usage grows after every collection.
- Pauses spike during peak traffic.
- Allocation rate suddenly increases.
- Humongous allocations dominate G1 behavior.
- OutOfMemoryError appears after long GC thrashing.
Use Java Flight Recorder, Java Mission Control, jcmd, jstat, GC log analyzers, APM memory metrics and heap dump analysis together. GC logs explain collection behavior; heap dumps explain what objects are retained.
OutOfMemoryError and GC Overhead: What the JVM Is Telling You
An OutOfMemoryError is not always solved by increasing -Xmx. It can be a real memory leak, a container memory limit mismatch, too many threads, direct memory pressure, Metaspace growth, cache explosion, bad object retention, or a collector/heap sizing problem.
Heap cannot satisfy allocation
Check retained objects, caches, request bodies, collections, ORM sessions, JSON payloads and old-gen growth.
Too much time collecting
The JVM may be spending excessive time in GC while recovering very little memory. This often means the live set is too large.
Class metadata issue
Dynamic class loading, hot reload, classloader leaks or too many generated classes can grow Metaspace.
Off-heap can still kill you
ByteBuffers, Netty, native libraries and memory-mapped files can consume memory outside the Java heap.
Stacks use memory too
Thousands of platform threads can consume stack memory. Check thread count and stack size before blaming the heap.
Not always a Java exception
Kubernetes or Docker may kill the process when total RSS crosses the container limit, even if Java heap looks reasonable.
Java Garbage Collection in Docker and Kubernetes
Container memory changes GC planning. The JVM heap is only one part of process memory. Native memory, thread stacks, Metaspace, code cache, GC structures, direct buffers and OS overhead also need room.
Leave non-heap headroom
Do not set -Xmx equal to the container memory limit. Leave room for native memory, threads, buffers and JVM overhead.
GC threads need CPU
Low CPU limits can make concurrent collectors fall behind and can stretch pauses or background GC work.
Scale before GC panic
If traffic spikes cause allocation spikes, horizontal scaling may be better than endless heap tuning.
# Example container-friendly baseline:
java \
-XX:MaxRAMPercentage=70 \
-Xlog:gc*,safepoint:file=/logs/gc.log:time,uptime,level,tags \
-jar app.jarMeasure total process memory, not only heap usage. A service can be killed by the container platform even when GC logs look normal.
Which Java Garbage Collector Should You Choose?
Choose based on workload, not fashion. A batch job, low-latency API, desktop utility, trading system, search service, Minecraft server, Spring Boot API and Kafka-like data pipeline can need different GC behavior.
You need a balanced default
G1 is a good first test for many web services, enterprise apps and medium-to-large heaps where you want reasonable pause control and throughput.
Latency matters most
Test ZGC for strict latency goals, very large heaps or services where long pauses are unacceptable and extra CPU or memory headroom is acceptable.
Throughput beats pauses
Parallel GC can fit batch processing, data conversion and non-interactive jobs where total completion time is more important than short pauses.
The app is tiny
Serial GC can fit small tools, small heaps, single-core test cases or constrained simple workloads.
Your build supports it
Shenandoah can be a strong low-pause option in OpenJDK builds that include it. Test with your actual JDK distribution and platform.
Benchmark your own app
Allocation patterns, object graph, cache behavior, CPU limits and traffic shape matter more than generic benchmark claims.
Common Java GC Mistakes That Hurt Production
Most GC incidents come from a few repeat mistakes: unbounded memory growth, wrong container sizing, too many copied flags, weak monitoring and late heap dump collection.
Healthy GC operations
- Set clear heap limits.
- Enable GC logs in production.
- Use Java Flight Recorder during incidents.
- Watch old-gen after-GC trends.
- Use bounded caches and queues.
- Load test before changing collectors.
- Keep enough container memory headroom.
GC anti-patterns
- Calling
System.gc()on a timer. - Copying 20 JVM flags without understanding.
- Setting
-Xmxequal to container memory. - Ignoring Full GC warnings.
- Disabling logs to save tiny disk space.
- Using unlimited maps, lists and caches.
- Assuming every OutOfMemoryError is a heap-size problem.
Official Java Garbage Collection Resources
Use official and project documentation when making production decisions. Blogs can explain concepts, but JVM flags and supported collectors depend on your JDK version, vendor and platform.
Java Garbage Collection FAQ
Does Java garbage collection run on a fixed schedule?
No. Java GC is not based on a fixed pickup day or calendar. The JVM runs GC based on heap pressure, allocation rate, collector policy, generational thresholds and runtime conditions.
Can I force garbage collection in Java?
You can call System.gc(), but it is only a request. The JVM may ignore, delay or handle it differently depending on flags and collector behavior. It is not a good production scheduling strategy.
Which Java garbage collector should I use?
Start with your supported JDK default unless you have measured evidence. G1 is a practical baseline for many services. ZGC and Shenandoah are useful for low-latency workloads. Parallel GC can fit throughput-heavy batch jobs.
Is G1 GC better than ZGC?
Neither is universally better. G1 is a balanced collector with good general behavior. ZGC targets very low pause times and large heaps, often with different CPU and memory trade-offs. Test with your workload.
What causes Full GC in Java?
Full GC can happen because of old-generation pressure, allocation failure, metadata pressure, explicit GC requests, fragmentation or collector-specific emergency conditions. Frequent Full GC should be investigated.
Does increasing heap size fix GC pauses?
Sometimes it helps, but not always. A larger heap can reduce frequency but may increase the cost of some collections. Memory leaks and unbounded caches need code or configuration fixes, not only more heap.
How do I enable Java GC logs?
On Java 9 and newer, use unified logging such as -Xlog:gc*,safepoint:file=gc.log:time,uptime,level,tags. Rotate logs in production so files do not grow forever.
What is a memory leak in Java if GC exists?
A Java memory leak means objects remain reachable even though the application no longer needs them. GC cannot collect reachable objects held by caches, maps, thread locals, listeners or static references.
Is Shenandoah available in every JDK?
No. Shenandoah availability depends on the JDK distribution and platform. Check your vendor’s documentation and test the flag before using it in production.
What is the best GC for Kubernetes?
There is no single best GC for Kubernetes. Choose based on latency goals, heap size, CPU limits and memory headroom. Always leave non-heap memory room below the container limit.
Editorial and Source Verification Note
This independent garbage-collection.org guide was prepared using official Java and OpenJDK documentation, including Oracle Java GC tuning documentation, Oracle collector guidance, Oracle G1 documentation, OpenJDK ZGC project pages, JEP 439 for Generational ZGC, OpenJDK Shenandoah project information and Java Mission Control resources.
Always verify JVM flags, default behavior, supported collectors and tuning recommendations against your exact Java version, JDK vendor, operating system, container platform and production workload before changing garbage collection settings.
Final Summary: Java Garbage Collection Has a Policy, Not a Pickup Day
Java garbage collection is automatic memory management inside the JVM. It does not follow a fixed daily schedule. GC runs when the JVM decides memory should be reclaimed based on heap pressure, allocation behavior, collector strategy and runtime goals.
For most teams, the practical answer is: use a supported JDK default or G1 baseline, enable GC logs, measure real traffic, avoid System.gc() scheduling, keep enough heap and container headroom, and test ZGC or Shenandoah only when latency requirements justify it. If Full GC or OutOfMemoryError appears often, collect evidence before changing random flags.