RecursiveTask中是否锁定了Spring托管的bean

Question

技术栈

• Web应用程序
• Java 1.7
• Spring框架4

问题

1. 我需要能够处理应用程序中包含文档的ZIP文件，然后以递归方式解压缩它们。我的意思是递归-如果ZIP包含其他ZIP文件，它们也应该解压缩。然后，应处理所有档案中的所有文档。

2. 点1应该并行执行，以加快处理速度。

实作

• 我决定使用Java 7中引入的ForkJoinFramework。因此，我最终获得了Spring托管的单例服务ZipService（具有process（zip）方法），该服务使用Spring托管的ForkJoinPool来调用ZipPartitioner（我创建的RecursiveTask，用于从服务器中对内容进行分区ZIP文件）。所述ZipPartitioner的compute()方法检查，如果该组的ZIP内容是足够小（文档集合大小为1）直接计算，还是应与分隔继续。如果应该直接计算，则检查当前内容/文件是否实际上是要处理的文件，还是另一个（嵌套的）ZIP。这是有趣的部分-当我创建我将ZipService中的ZipPartitioner传递this给其构造函数，因此我对ZipService进行了引用。然后，如果直接在计算逻辑中发现内容实际上又是一个ZIP，那么我从ZipService的引用中调用process（zip）方法，以便该过程可以递归地重新开始。

结果

• 令人惊讶的是，该实施效果很好，并减少了3倍的处理时间。然后，我决定使用JMeter对实现进行基准测试。它可以同时处理5个并发请求，但可以处理10个以上的请求。当ZipPartitioner尝试在ZipService的实例上调用process（zip）方法时，执行将阻塞。ForkJoinPool中有多少个线程都没关系-我检查了1，10，30和1000。

题

• 我认为这种方法通常存在一些错误-将Spring托管的bean传递给RecursiveTask，但是它可以处理较小的请求数。那么有人能指出我为什么会中断以及为什么会起作用吗？您将如何解决这个问题？
• 我怀疑随后对ZipService的请求以某种方式使Spring锁定了它，并且这种方式阻止了generateDirectly方法的递归调用。您是否在我的想法中发现了有意义的东西，或者它们是垃圾？

让我知道我的解释中有哪些不清楚的地方（我敢打赌会有些东西）。

Answer 1

一些建议应该会有所帮助：

• 执行线程转储（例如，使用visualvm）并查看被阻止的内容
• 尽量减少分叉的任务数量
• 考虑迭代而不是递归