How to Crash Your JVM

There are so many new APIs, cool libraries, and must-try techniques you need to know that it can be hard to stay up to date.

But is this really all you need to know as a Java developer? What about the environment your software is running in? Couldn’t it be that a problem here could crash your software, and you wouldn’t even be able to understand or find that problem because it is outside the world of libraries and code? Are you prepared to consider another perspective?

Here is a challenge: Try to find ways to crash your Java Virtual Machine! (Or, at least, bring its normal execution to a sudden and unexpected stop.) The more ways you know, the better you understand your surroundings and appreciate what can go wrong with a running software system.

Here’s a few to get you started:

1. Try to allocate as much memory as you can. RAM is not endless — if no more RAM can be allocated, your allocation will fail.
2. Try to write data to your hard disk until it is full. Same problem as with the RAM: though bigger than RAM, disk space is not endless either.
3. Try to open as many files as you can. Do you know the maximum number of file descriptors for your environment?
4. Try to create as many threads as you can. On a Linux system, you can look at /proc/sys/kernel/pid_max and you will see how many processes may be running on your system. How many threads are you allowed to create on your system?
5. Try to modify your own .class files in the file system — the current run of your application will be its last!
6. Try to find our your own process id, and then try to kill it using using Runtime.exec, e.g., by calling kill -9 on your process id.
7. Try to create a class at runtime which only calls System.exit, load that class dynamically via the class loader, then call it.
8. Try to open as many socket connections as possible. On a Unix system, the maximum number of possible socket connections equals the maximum number of file descriptors (often 2048). How many are available where your application is running?
9. Try to hack your system. Download an exploit via code or by using wget. Execute the exploit, and then call shutdown -h now as root on a Unix system or shutdown /s as administrator on a Windows system.
10. Try jumping without a safety net. Part of Java’s safety comes from its language design; part from the bytecode verification in your JVM. Run your JVM with -noverify or -Xverify:none, which disables all bytecode verification, and write something that would otherwise not be allowed to run.
11. Try using Unsafe. This backdoor class is used to get access to low-level facilities, such as memory management. All the syntax of Java; all the safety of C!
12. Try going native. Write some native code. All the syntax of C; all the safety of C!

Try to find your own ways to crash your VM and ask colleagues for their ideas. Also consider asking job interview candidates how they might go about this. Whatever their answer, you will soon learn whether the interviewee is able to see the world outside their IDE window.

P.S. If you find other creative ways to crash a JVM, please let me know!