On 04/01/2018 01:35, David Holmes wrote:
You're not missing anything. It's a class initialization related
"deadlock".
Thread A has called FileSystems.getDefault() which is doing <clinit>
of DefaultFileSystemHolder, which in turn leads to
Runtime.loadLibrary0 which needs to lock the Runtime instance.
Thread B is already doing a loadLibrary and holds the Runtime lock,
the loadLibrary code then needs to do FileSystems.getDefault() which
has to load and initialize DefaultFileSystemHolder, but that
initialization is already in progress so internally the thread does a
wait().
So Thread B is waiting for Thread A to finish initialization, but
holds the monitor lock that Thread A needs to finish the
initialization. Deadlock.
AFAICS this will still be possible in 9/10/11
Startup and initialization has changed quite a bit since JDK 8. In JDK 9
the file system is initialized early (long before main). However, it
changes again in JDK 10 due to ongoing work to makes things lazy and
improve startup time. Separately, FilePermission and the JarFile support
have been re-written so it should be loaded before any user code
executes. So I think needs to be studied again, I agree with your other
mail to create a bug to track that.
-Alan
