出现java.lang.OutOfMemoryError: Java heap space该错误或者是程序问题，或者被分配到JVM内存真的是不够的。
一般来说都是能够事前可控解决的。
可是假设不可控的情况。比如使用第三方包，或者系统抽筋，就会抛出OutOfMemoryError错误。
OH NO，依据不会抛出来，当前线程直接挂掉。
既然都挂掉了，谈什么恢复？并且挂掉也不仅仅是OutOfMemoryError的问题。
普通情况下，OutOfMemoryError在不可控的情况下。真的真的真的不须要处理，干脆无视好了。就当是运气好吧。
并且解决起来。程序逻辑非常难看。
假设你想较真，出现OutOfMemoryError时想死得好看一点，或者恢复起来优雅一点，那继续。
先了解OutOfMemoryError的一些特点：
1，不确定不可控性。相信可控的情况你已经攻克了。
2，不会抛出异常，也就是说try...catch不起作用。
3，出现后，当前线程就会挂掉。
4，对3点，假设在try...finally里发生OutOfMemoryError，则会运行finally语句再挂掉。但不要以为try...finally是万能的，什么情况都能得到运行。你用exit或者关机试试。
5，对3点，假设是多线程中的一个子线程(非守护)，挂掉不影响其他线程。而且内存非常快(是非常快，就是非常快)能够回收。
所以在你确定会遇到OutOfMemoryError但无法解决的时候，try...finally是实用的，仅仅要不再做非常多内存的操作吧，想继续什么流程都没什么问题(我没遇到有问题的情况而已)。退出是必定的，finally里还是须要善后。记录状态等。还要记得用无关要紧的独立的线程去处理，最后通过守护程序，监控程序或者定时器又一次启动一个处理线程就是了。
====后记====
这几天用TIKA抽取文档内容并做索引。在抽取某个才40M(其他上百M以上的都没有问题)的文档时出现OutOfMemoryError，内存一下就用完了，加大到系统的上限也没用，照样完了，所以运行会停止。文档是不停地添加，并你要提取的索引的内容，为了保持该方案顺利运行，因此，上述探索。
版权声明：本文博客原创文章，博客，未经同意，不得转载。