出现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，内存一下就用完了，加大到系统的上限也没用，照样完了，所以运行会停止。文档是不停地添加，并你要提取的索引的内容，为了保持该方案顺利运行，因此，上述探索。