Investigating JDK-8174817, there was a few troubling finds in the jimage code:

ImageReader.reader is non-volatile, and there appears to be no effective guard to ensure it's safely published (even though it's created under a lock), thus it might be possible for a thread to observe the reader field as null and thus interpret the reader as closed in some situations.

There's also a race in ImageReaderFactory managed by getting, checking, opening and doing a putIfAbsent (the ImageReader who lose the race will be closed); this could be implemented better using computeIfAbsent