我有一个java应用程序，它可以读取microsoft word文档（*.docx），并从文档内容中创建新内容。它在许多方面都是一个简单的批处理应用程序。它从指定目录中获取的文档列表中工作。它递归此目录的所有子文件夹，并创建一个字符串列表，这些字符串是docx文档的名称。然后一次处理一个列表。它工作正常，在大约35分钟内处理所有288个文档，并为每个文档生成正确的输出。在它的单线程形式，它已经在我使用了三年没有问题。在本例中，“correct”是我定义的，因为它是我的应用程序。我应该说，我很少运行整个288—只有在添加新特性时才运行。
288个文档中有许多是大的——400页或更多。因为我的电脑是一个核心i7，它有4个核心，每个核心有两个并发线程的能力，我想同时运行这些文件，看看它是否可以更快。我试过使用 ThreadPoolExecutor 但我得到了一个 StackOverflowError 大概有20%的人会通过名单。很明显 StackOverflowError 不是由子文件夹递归引起的。
这仅仅是确保每个文档创建的对象本身超出范围的问题，还是有一种建议的“强制”它们释放内存的方法，比如设置为 null 最后？我已经试着做了这两个部分，但都没有成功，我要花一个星期的时间才能完全做到。有没有更好的或推荐的策略？
docx文件格式（微软称之为officeopenxml）是一个包含xml文件的zip文件，我使用xslt将其转换为自己的格式。这一部分非常简单——使用JavaZipFile和jaxp。
这个应用程序是根据图书馆的原则编写的 Shelf 对象包含 Book 对象包含 Chapter 物体。一般每本书有10到20章，每本书有300-500页左右，目前算288本，还有100多本在路上。
总的来说，应用程序是超过10000行代码，所以不可行的代码后。我删除了一些实验性的代码行 ExecutorService --这是一个非常简单的api Package Runnable ，我用的是谷歌的例子。我会试着重做一个例子，我做了什么，并张贴它。