RecursiveTask中的Spring是否存在锁定

Question

技术栈

• Web应用程序
• Java 1.7
• 春季框架4

问题

1. 我需要能够处理应用程序中包含文档的ZIP文件，递归地解压缩它们。我的意思是递归地-如果ZIP包含其他的ZIP文件，它们也应该被解压缩。然后对所有档案中的所有文件进行处理。
2. 第1点应并行执行，以加快进程。

Implementation

• 我决定使用Java 7中引入的process(zip)，因此我最终让singleton服务ZipService (拥有ZipPartitioner方法)使用Spring托管ForkJoinPool调用ZipPartitioner(我为从ZIP文件中分区内容而创建的RecursiveTask )。ZipPartitioner's compute()方法检查ZIP内容集是否足够小(文档集大小为1)可以直接计算，还是应该继续分区。如果应该直接计算，我会检查当前的内容/文件实际上是要处理的文件还是另一个(嵌套的) ZIP。下面是有趣的部分--当我创建ZipPartitioner in ZipService时，我将this传递给它的构造函数，因此我引用了ZipService。然后，如果在计算直接逻辑中再次发现内容实际上是ZIP，我将从ZipService's引用调用ZipService‘s方法，以便进程可以递归地重新开始。

结果

• 令人惊讶的是，该实现非常有效，并缩短了3次处理时间。然后我决定用JMeter对实现进行基准测试。它在5个并发请求中运行良好，但与10+请求挂起。当ZipPartitioner试图调用ZipService's实例上的process(zip)方法时，执行阻塞。不管ForkJoinPool中有多少线程--我用1、10、30和1000进行了检查。

问题

• 我认为这种方法通常是错误的--将Spring传递给RecursiveTask，但是它可以处理较小的请求号。有人能告诉我为什么会这样吗?为什么会这样？你会如何处理这个问题？
• 我怀疑对ZipService的后续请求以某种方式使Spring锁定了它，从而阻止了来自computeDirectly方法的递归调用。你在我的思想里找到了什么有意义的东西吗?还是它们是垃圾？

让我知道在我的解释中什么是不清楚的(我打赌会有什么)。

Answer 1

以下几点建议应该有所帮助：

• 执行线程转储(例如，使用visualvm)，并查看哪些被阻塞
• 尽量减少分叉任务的数量。
• 考虑迭代而不是递归