-
Bug
-
Resolution: Unresolved
-
P4
-
None
-
19, 21, 25
-
None
In 2015, Google discovered a rare disastrous classloading bug in first call to LockSupport.park() that occurred in the AppClassLoader using the Java 7 ConcurrentHashMap, which used ReentrantLock for the synchronization.
Since then, the recommended fix for this bug seems to be this code snippet in any class that directly calls LockSupport.park():
static {
// Prevent rare disastrous classloading in first call to LockSupport.park.
// See: https://bugs.openjdk.java.net/browse/JDK-8074773
Class<?> ensureLoaded = LockSupport.class;
}
Since the bug was logged, we have seen new classes in the JDK that call LockSupport.park(), but that do not have this code snippet. For example:
sun.nio.ch.Poller
jdk.internal.misc.ThreadFlock
java.util.concurrent.ThreadPerTaskExecutor
It should probably also be in:
java.util.concurrent.Exchanger
Considering how hard this bug is to detect and solve, it would probably be safer to add the code snippet into these newer classes.
Since then, the recommended fix for this bug seems to be this code snippet in any class that directly calls LockSupport.park():
static {
// Prevent rare disastrous classloading in first call to LockSupport.park.
// See: https://bugs.openjdk.java.net/browse/JDK-8074773
Class<?> ensureLoaded = LockSupport.class;
}
Since the bug was logged, we have seen new classes in the JDK that call LockSupport.park(), but that do not have this code snippet. For example:
sun.nio.ch.Poller
jdk.internal.misc.ThreadFlock
java.util.concurrent.ThreadPerTaskExecutor
It should probably also be in:
java.util.concurrent.Exchanger
Considering how hard this bug is to detect and solve, it would probably be safer to add the code snippet into these newer classes.
- caused by
-
JDK-8074773 Rare lost unpark when very first LockSupport.park triggers class loading
-
- Closed
-
- links to
-
Review(master) openjdk/jdk/24952