从[java.lang.OutOfMemoryError: Java heap space]中恢复

        出现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，内存一下就用完了，加大到系统的上限也没用，照样完了，所以执行会停止。文档是不停地增加，并要抽取内容做好索引，为了使程序能顺利不停地执行，所以有了上面的探索。