Over a million developers have joined DZone.

Method 2 of N for crashing your JVM

DZone's Guide to

Method 2 of N for crashing your JVM

· Java Zone ·
Free Resource

Download Microservices for Java Developers: A hands-on introduction to frameworks and containers. Brought to you in partnership with Red Hat.

On a previous post there was a short discussion about what’s the best way to clean up memory mapped files and Philippe brought to my attention the following text from a bug report:

With regard to the “workaround”, described in the JDC comments, of (ab)using reflection in order to invoke a mapped buffer’s cleaner object: This is highly inadvisable, to put it mildly. It is exceedingly dangerous to forcibly unmap a
mapped byte buffer that’s visible to Java code. Doing so risks both the security and stability of the system.

So what is the problem with doing ((sun.nio.ch.DirectBuffer) buffer).cleaner().clean();?

As explained briefly in the bug post, there are two potential issues:

  • The first potential issue is that you might try to read/write from/to the buffer after calling the cleaner (because you have a bug in the code). This will bring down the JVM with SIGSEGV on Linux / EXCEPTION_ACCESS_VIOLATION under Windows
  • The second potential issue is that somebody might remap an other file in the same address range after you’ve unmapped your file and you start to read (or even worse – write) to a different file.

Both of these issues are solved if you let the GC clean up the mappings (since when it runs you’re guaranteed that there are no other references to the object), but it might never collect your buffers.

An other possibility is to wrap the code up in a library which “does the right thing” (like Chronicle).

Finally, you could (and should) carefully design your program to avoid repeated (re-)allocation (ideally you should do all the allocations at startup and leave things alone afterwards). Besides removing the potential for the above issues, allocating direct memory buffers is a costly endeavor with the JVM: it is globally synchronized and it may trigger a GC and/or sleep (see FileChannelImpl.java and Bits.java).

Download Building Reactive Microservices in Java: Asynchronous and Event-Based Application Design. Brought to you in partnership with Red Hat


Published at DZone with permission of

Opinions expressed by DZone contributors are their own.

{{ parent.title || parent.header.title}}

{{ parent.tldr }}

{{ parent.urlSource.name }}