Build Log

Not All Java Concurrency Bugs Throw ConcurrentModificationException

2025-11-07T00:00:00.000Z

As Java developers, we often rely on collections like ArrayList and HashMap in our day-to-day coding. These collections are incredibly convenient, but there’s a subtle trap many intermediate developers encounter: concurrent access to non-thread-safe collections.

"If I access a non-thread-safe collection concurrently, Java will always throw a ConcurrentModificationException (CME)."

This isn’t true—and understanding why is a mark of a more senior developer.

The Reality

ConcurrentModificationException is not a catch-all for concurrency issues in collections. It is a fail-fast mechanism designed to detect some, but not all, unsafe modifications during iteration.

Fail-fast iterators are a convenience, not a safety net. Here’s what that means:

1. Iterating while modifying

List<Integer> list = new ArrayList<>(Arrays.asList(1, 2, 3));
for (Integer i : list) {
    list.add(4); // Might throw ConcurrentModificationException
}

This will likely throw CME because the iterator detects the modification.

2. Concurrent writes without iteration

List<Integer> list = new ArrayList<>();
Thread t1 = () -> list.add(1);
Thread t2 = () -> list.add(2);

t1.start();
t2.start();

Here, no iteration is happening, so no CME occurs, but the list may end up in a corrupted state or have lost updates. The JVM gives no warning, which can lead to subtle, hard-to-diagnose bugs.

Key Takewaways

CME is best-effort detection, not a guarantee.
Non-thread-safe collections are vulnerable to silent corruption, lost updates, and unpredictable behavior under concurrency.
To safely handle concurrent access, use:
- Collections.synchronizedList(...) or Collections.synchronizedMap(...)
- Concurrent collections like ConcurrentHashMap, CopyOnWriteArrayList, or ConcurrentLinkedQueue

Why This Matters

Understanding the difference between fail-fast exceptions and real concurrency safety is a key step toward writing robust, maintainable Java code. Senior developers not only write code that works—they anticipate subtle failure modes and choose the right tools to prevent them.

Pro Tip: Don’t rely on ConcurrentModificationException to tell you your code is thread-safe. Treat it as a helpful signal, not a safety net.

---
title: Not All Java Concurrency Bugs Throw ConcurrentModificationException
description: Understanding why ConcurrentModificationException isn’t a safety net and how concurrent access can silently break Java collections
date: 2025-11-07
keywords: [java,concurrency]
---

Kernel-Level Threads vs User-Level Threads (and Why It Matters in Modern Java)

2025-11-03T00:00:00.000Z

Introduction

Concurrency is a cornerstone of modern computing. Whether you’re writing a high-performance web server or parallelizing data processing, understanding how threads are managed—both by the operating system and the runtime—helps you design more scalable, efficient systems.

In Java, this distinction has become even more important with the introduction of Virtual Threads in Project Loom, which effectively reintroduces user-level threading to the JVM world. Let’s explore what that means by comparing kernel-level (platform) threads and user-level threads.

Overview of Thread Types

Threads allow multiple tasks to execute concurrently within the same process. How these threads are managed depends on the layer of control:

Kernel-Level (Platform) Threads: Managed directly by the operating system (OS).
User-Level Threads: Managed by a user-space library or runtime, without OS involvement.

Comparison of Kernel-Level Threads and User-Level Threads

Feature	Platform Threads	User Threads
Management	Managed by the operating system	A user-space library or runtime
Mapping	Each thread in your program corresponds 1:1 to a thread in the OS	Many user threads multiplexed onto fewer kernel threads
Parallelism	True paralleism with OS scheduling	Cooperative scheduling - often not parallel across cores
Creation Speed	Slower, as each thread requires OS resources	Extremely fast (no OS call needed)
Resource Usage	Higher (stack, scheduling overhead)	Very light
Blocking Behavior	Blocking system calls can suspend the entire OS thread	One blocked user thread does not necessarily block others (depending on runtime design)

Advantages / Disadvantages

Platform (Kernel-Level) Threads

Advantages

True hardware-level parallism
Direct access to OS scheduling and CPU cores

Disadvantages

Higher overhead to create and switch context
Limited scalability - thousands of OS threads can quickly exhaust resources

User Threads

Advantages

Lightweight and quick to create
Efficient for large numbers of concurrent tasks
Portable across platforms

Disadvantages

Limited parallism - often single-core execution unless runtime manages multiplexing
Harder to integrate with blocking I/O or system calls

Java's Evolution: From Platform Threads to Virtual Threads

Historically, Java threads were 1:1 mappings to OS (platform) threads. This meant creating thousands of concurrent tasks (eg, one thread per connection) was inefficient because each thread consumed a large stack and kernel resources.

Project Loom (introduced in Java 21) changed that. Virtual threads are user-level threads implemented by the JVM. They're scheduled by the Java runtime onto a smaller pool of platform threads.

This gives use the best of both worlds:

The simplicity of the familiar Thread API
The scalability of lightweight user threads

Example: Virtual Threads in Action

Here's a simple demonstration comparis traditional platform threads and virtual threads.

import java.util.concurrent.Executors;
import java.util.stream.IntStream;

public class VirtualThreadsDemo {
    public static void main(String[] args) throws Exception {
        try (var executor = Executors.newVirtualThreadPerTaskExecutor()) {
            IntStream.range(0, 1000).forEach(i ->
                executor.submit(() -> {
                    Thread.sleep(100); // Simulate blocking I/O
                    System.out.println("Task " + i + " running on " + Thread.currentThread());
                    return i;
                })
            );
        } // Executor closes automatically
    }
}

In older Java versions, creating 1000 threads like this would be expensive and could overwhelm the OS. With virtual threads, the JVM efficiently schedules them over a small number of kernel threads, giving you massive concurrency with minimal overhead.

Choosing the Right Threading Model

Scenario	Recommended Approach
CPU-bound tasks	Platform (kernel-level) threads
I/O-bound tasks (many concurrent connections)	Virtual (user-level) threads
Fine-grained concurrency, lightweight workloads	Virtual threads
Low-Level system access, custom schedulers	Platform threads

Key Takeaways

Platform threads offer true parallelism but come with higher cost.
User-level threads (like Java virtual threads) are lightweight and scalable but rely on runtime scheduling.
Java 21+ bridges the two worlds by offering virtual threads that behave like normal Threads but scale like coroutines.
Understanding how these thread models differ empowers us to design applications that are both efficient and maintainable in the era of high-concurrency systems.

Conclusion

As a Java developer, mastering concurrency isn't just about using synchronized or ExecutorService. It's about understanding what's happending under the hood - how threads are scheduled, how resources are managed, and how new models like virtual threads reshape our approach to scalability.

Whether you're optimizing backend performance or designing frameworks, knowing the difference between kernel-level and user-level threading will help us write code that's both faster and more future-proof.

---
title: Kernel-Level Threads vs User-Level Threads (and Why It Matters in Modern Java)
description: What is the difference between kernel-level threads and user-level threads?
date: 2025-11-03
keywords: [java,concurrency]
---

Healthy vs Non-Healthy Garbage Collection Behavior In The JVM

2025-10-28T00:00:00.000Z

Introduction

Ever watched your Java service slow to a crawl for no clear reason?
Often, the culprit isn’t your code — it’s your garbage collector gasping for air.

Garbage collection (GC) is the JVM’s built-in memory management mechanism, automatically reclaiming space from unreachable objects so you can focus on writing logic instead of worrying about leaks.
But GC activity is more than just a background process — it’s like your application’s heartbeat. Smooth, predictable GC behavior signals healthy memory use, while erratic or frequent GC events often reveal deeper performance issues: leaks, excessive allocation, or poor tuning.

In this post, we’ll explore what defines healthy vs. unhealthy GC behavior, how to interpret heap usage patterns, and how to correct GC issues before they impact performance.

What does "healthy" GC behavior look like

When the GC is functioning optimally, you'll see a stable rhythm of memory allocation and reclamation.

Typical Pattern

The heap gradual fills as the application allocates objects.
A GC event (young or full) reclaims unused memory.
Heap usage drops, and the cycle repeats predictably.

This creates the characteristic "saw-tooth" pattern in heap usage charts - often a sign of a healthy application.

"Heap usage will keep rising; once a Full Garbage collection ... occurs memory utilization drops all the way to the bottom ... It indicates that the application is in a healthy state & not suffering from any sort of memory problems." DZone: Interesting Garbage Collection Patterns

Traits of a Healthy GC

GC events are infrequent and quick.
Application throughput remains high.
Post-GC heap usage (the "baseline") stays consistent over time.

Note: With modern concurrent collectors like G1GC, ZGV, and Shenandoah, the saw-tooth pattern may appear smoother since these collectors perform most work concurrently, reducing large visibility drops.

What does "Unhealthy" GC behavior Look Like?

Unhealthy GC behavior indicates that your application or JVM configuration is struggling to manage memory efficiently.

Common Symptoms

Symptom	Description	Likely Causes
Frequent Full GCs	Full GCs happen seconds apart, consuming CPU and causing pauses	Heap to small, excessive allocation, old-gen promotion pressure.
Rising Heap Baseline	Memory after GC keeps growing after GC.	Objects are still strongly referenced.
GC Thrashing	JVM spends more time in GC than running the app.	Small heap, too amny short-lived objects, mis-tuned GC parameters
Promotion Failures / OOM	Objects move prematurely to old generation, eventually OOM	Survivor space exhaustian, high allocation churn.

Visual Examples: Healthy vs Unhealthy Patterns

Diagnosing GC Health

Understanding GC health requires monitoring metrics, and log analysis.

GC Logs

Enables GC logging in modern JVMs:

java -Xlog:gc*:file=gc.log:time,uptime,level,tags MyApp

Pattern	Description	Typical Cause
Healthy Saw-Tooth	Heap rises and falls predictably with GC cycles	Balanced allocation and reclaimation
Rising Baseline	Each GC leaves more memory retained	Memory leak or poor caching logic.
Flag / No Drop	Heap stays high even after GC	Retained strong references.
Frequent Spikes	Constant GCs reclaim little memory	Heap too small or allocation too fast

Parameter	Description
`java`	Runs the Java Virtual Machine (JVM).
`-Xlog:gc*`	Enables detailed logging for all garbage collection events.
`file=gc.log`	Writes logs to a file (`gc.log`) for later analysis.
`time`	Includes wall-clock timestamp of each event.
`uptime`	Adds time since JVM startup.
`level`	Includes log severity (info, warning, etc.).
`tags`	Includes event tags (gc, heap, pause, etc.).
`MyApp`	The Java class containing the `main` method to run.

Monitoring Tools

Tool	Description
VisualVM	live heap and GC charts
Java Mission Control (JMC)	Advanced Profiling And Flight Recordings
Grafana & Prometheus	Dashboards

Key Metrics to Watch

Metric	What It Tells You	Health Range / Guidance
GC Pause Time	Duration of stop-the-world events.	<200ms for latency specific systems.
GC Frequency	How ofen the GCs occur	Should scale with allocation rate, not spike randomly.
Heap after GC	Post-collection heap usage.	Should stay roughly stable over time.
Allocation Rate	Object creation speed	Excessive rates -> rune caching or reuse objects

Keeping Your GC Healthy

Right-Size Your Heap

Set -Xms and -Xmx to match actual usage.
Avoid setting them too small - causes frequent GCs.
Avoid excessive heap - delays leak detection.

Pick the Right GC Algorithm

G1GC (default since JDK 9): Balanced throughput and latency.
ZGC / Shenandoah: Ultra-low pause times, ideal for large heaps.
Parallel GC: Best for batch jobs with high CPU throughput.

Reduce Object Churn

Reuse objects and buffers
Use primitive collections (eg. TIntArrayList) to reduce boxing.
Avoid temporary object floods (e.g., string concatenation inside loops).

Profile and Analyze Regularly

Use memory profiles (JMC, Eclipse MAT) to spot leaks.
Investigate any rising heap baselines early.

Example: Diagnosing a Leak via GC Pattern

Heap baseline keeps rising every hour.
GC logs show increasing "used after GC" values.
Heap dump analysis reveals a large ConcurrentHashMap holding cached objects with no eviction policy.
Fix -> Add cache expiration -> GC returns to steady saw-tooth-pattern.

Conclusion

Health garbage collection isn't about minimizing GC activity. It's about maintaining a predictable, balanced cycle where memory is reclaimed efficiently and the application spends most time doing real work.

When GC becomes erratic, too frequent, or too ineffective, it's a sign to:

Reassess heap sizing and GC algorithm choice.
Analyze object allocation patterns.
Fix leaks and optimize caching.

With consistent monitoring and tuning, we can keep the JVM's "heartbeat" steady - ensuring high throughput and long-term stability.

Build Log

Not All Java Concurrency Bugs Throw ConcurrentModificationException

The Reality

1. Iterating while modifying

2. Concurrent writes without iteration

Key Takewaways

Why This Matters

Kernel-Level Threads vs User-Level Threads (and Why It Matters in Modern Java)

Introduction

Overview of Thread Types

Comparison of Kernel-Level Threads and User-Level Threads

Advantages / Disadvantages

Platform (Kernel-Level) Threads

Advantages

Disadvantages

User Threads

Advantages

Disadvantages

Java's Evolution: From Platform Threads to Virtual Threads

Example: Virtual Threads in Action

Choosing the Right Threading Model

Key Takeaways

Conclusion

Healthy vs Non-Healthy Garbage Collection Behavior In The JVM

Introduction

What does "healthy" GC behavior look like

Typical Pattern

Traits of a Healthy GC

What does "Unhealthy" GC behavior Look Like?

Common Symptoms

Visual Examples: Healthy vs Unhealthy Patterns

Diagnosing GC Health

GC Logs

Monitoring Tools

Key Metrics to Watch

Keeping Your GC Healthy

Right-Size Your Heap

Pick the Right GC Algorithm

Reduce Object Churn

Profile and Analyze Regularly

Example: Diagnosing a Leak via GC Pattern

Conclusion

Further Reading