You've been writing Java for years. You think you know it. You don't.
There's a special kind of confidence that comes after a few years of Java. You've survived generics. You've stared down the garbage collector. You've argued about whether checked exceptions were a mistake (they were). You feel safe.
You're not safe.
Java has corners. Dark ones. Places the docs gloss over, the tutorials skip, and the interviewer never asks about — until production is on fire at 2am and you're staring at a stack trace that makes no sense.
Let's go there.
1. String.format is not your friend under load
You've used it ten thousand times. It's readable. It's civilized. It's also one of the sneakiest performance traps in the JDK.
// Looks innocent. Isn't.
logger.debug(String.format("Processing order %s for user %s", orderId, userId));
Here's what most devs miss: String.format uses java.util.Formatter internally, which allocates a new Formatter object, a StringBuilder, and runs a regex-based parser on your format string — every single call.
In a hot path, this is brutal. Use String.valueOf() + concatenation (the compiler optimizes it to StringBuilder), or better yet — if you're on Java 15+ — text blocks and formatted() with proper caching.
And if you're still calling String.format inside a log statement without checking isDebugEnabled() first? Fix that before you close this tab.
2. HashMap has a trapdoor called hash collision amplification
You know HashMap degrades from O(1) to O(n) under hash collisions. Fine, textbook stuff. But here's what the textbook doesn't tell you:
Before Java 8, a pathological attacker (or a badly-designed key class) could reduce a HashMap to O(n) by simply engineering collisions. This was a real CVE. JSON parsing libraries that used HashMap for keys were vulnerable to hash-flooding DoS attacks.
After Java 8, the JDK added treeification — once a bucket hits 8 entries, it converts to a red-black tree, bringing worst case back to O(log n). But here's the trap:
record Point(int x, int y) {
@Override
public int hashCode() {
return x ^ y; // "looks fine"
}
}
(0,1) and (1,0) and (0,0) and... you see the problem. XOR is symmetric in ways that cluster your keys. In a spatial data structure with millions of points, you've just handed yourself a treeified nightmare.
Rule: If you override hashCode, use Objects.hash() or multiply by a prime. No cleverness.
3. Optional was never meant for what you're using it for
The original intent of Optional, per Brian Goetz himself: a return type for methods that might not have a value. That's it.
Not a field type. Not a method parameter. Not a collection element.
// Every senior dev has seen this and died inside
public class User {
private Optional<String> middleName; // NO
}
Optional is not serializable. It doesn't play well with Jackson without custom configuration. It adds allocation overhead. And it signals to anyone reading your code that you fundamentally misread the javadoc.
The real dark corner: Optional.get() is worse than a null check. If you're calling get() without isPresent(), you've replaced a NullPointerException with a NoSuchElementException and gained nothing — except you now have to unwrap it manually and the compiler won't warn you.
Use orElse, orElseGet, map, filter. Or switch to Kotlin where nullability is a first-class citizen and this whole conversation disappears.
4. == on Integer will burn you exactly at ±127
This one is ancient. Senior devs know it. And senior devs still get burned by it, because it only fails at a specific threshold.
Integer a = 127;
Integer b = 127;
System.out.println(a == b); // true
Integer c = 128;
Integer d = 128;
System.out.println(c == d); // false
The JVM caches Integer instances for values between -128 and 127. Outside that range, autoboxing creates new objects. == compares references. You get false.
The reason this is dangerous for seniors specifically: you know to use .equals() for strings. You've internalized it. But Integer feels primitive enough that == feels right. It isn't.
Where this actually kills you in production: comparison logic in service layers that works fine in unit tests (with small IDs or status codes) and fails mysteriously with real data.
Always use .equals(). Always.
5. ConcurrentHashMap doesn't make your compound operations atomic
This is the one that humbles people.
ConcurrentHashMap is thread-safe. Individual operations like get, put, remove are atomic. But the moment you do two operations in sequence, you've lost the guarantee.
ConcurrentHashMap<String, Integer> counts = new ConcurrentHashMap<>();
// This is a race condition, full stop
if (!counts.containsKey(key)) {
counts.put(key, 1);
} else {
counts.put(key, counts.get(key) + 1);
}
Between containsKey and put, another thread can — and will — do the same thing. You now have the wrong count.
The fix: compute, computeIfAbsent, merge. These are atomic. The JDK gave you the tools in Java 8. Use them.
counts.merge(key, 1, Integer::sum); // atomic, correct, one line
The dark corner within the dark corner: putIfAbsent is also not the fix for the check-then-act pattern unless you are genuinely only initializing. Know which operation matches your intent.
6. The finally block can silently swallow your exception
try {
throw new RuntimeException("the real problem");
} finally {
throw new RuntimeException("the distraction");
}
What gets thrown? The second one. The original exception is gone. No chaining, no suppressed list, nothing. Your real error evaporated.
This is especially vicious with return in a finally block:
try {
return computeSomething(); // throws
} finally {
return fallback(); // silently wins
}
The exception is swallowed. The caller gets fallback()'s return value and has no idea anything went wrong. This pattern is a production debugging nightmare.
Rule: Never return or throw from finally. If you must catch in finally, use addSuppressed() to preserve the original exception.
7. Virtual threads will expose your hidden blocking code (and that's the point)
Java 21's virtual threads are genuinely transformative — but they're a lie detector, not a magic wand.
The pitch: mount thousands of virtual threads on a handful of OS threads. When a virtual thread blocks (I/O, sleep, etc.), it unmounts, freeing the carrier thread. Massive throughput with minimal resources.
The trap: synchronized blocks pin the virtual thread to its carrier.
synchronized (this) {
someBlockingIoCall(); // pins the carrier thread. now you've lost the benefit.
}
With virtual threads, synchronized + blocking I/O is worse than before — you've created the illusion of concurrency while secretly serializing on your carrier pool.
The fix is to use ReentrantLock instead of synchronized. But that requires you to actually audit your code — including every library you've pulled in. If your JDBC driver uses synchronized internally, you're blocked.
Virtual threads don't make your code concurrent. They make your blocking code cheaper — as long as your blocking code cooperates.
The pattern underneath all of this
Notice what all seven of these have in common: they're not bugs. They're correct behavior that surprises you.
Java does exactly what the spec says. The problem is that the spec doesn't always match your mental model, and the gap between those two things is where production incidents live.
The senior move isn't memorizing this list. It's developing a healthy paranoia: when this seems too simple, what am I missing?
Write it down. Teach it to your team. And next time you're 100% sure about how something works in Java — go read the source.
What's your favorite Java dark corner? Drop it in the comments. I'll add the worst ones to a follow-up.
Top comments (0)