Note that clueless commenters/naysayers may come up with non-sense like "you should never catch an OOM" but they've probably never worked on Real-World [TM] Java applications being deployed on hundreds of systems. I do this all the time and it just works. This has allowed me to remotely debug and fix lots of very subtile memory leak that never ever showed up during testing. Catching an OOM here makes perfect sense because the whole point is to understand why the OOM is happening. But don't be surprise to see lots of naysayers here don't understanding that very basic fact.
– SyntaxT3rr0rMay 7 '10 at 12:18

Based on this answer, I created utility class UncaughtExceptionLogger (pastebin.com/e30g9y66). This one you can define, say, as a Spring bean, and you're all set with extended logging.
– snowindyDec 17 '14 at 4:37

Actually, it turns out that you can just load your Heap Dump generated on OOME into VisualVM and click on the "Show Threads" link under the "Threads at the heap dump" section title.
– Jim BethancourtMay 25 '10 at 17:48

I don't think there is anything in java that would provide you with on-exit thread dumps. I tackle this when necessary by having a cronjob that does periodic kill -3 pid. Yes, it does clutter the logs a bit, but the footprint is still negligible.

And if you are suffering from OOM, it might be be beneficial to see how the situation evolved thread-wise.