JBoss线程模型vs Java 5任务执行框架

Question

我需要在java中开发一个简单的守护进程，它从文件夹获取文件，分析它们的内容并将一些信息存储在数据库中。不可避免地会爆发一些活动（例如，在恶魔未运行时累积文件），我正在寻找最有效的线程模型来尽快处理积压。

我目前正在考虑几个选项。

1. 带有Quartz的JBoss AS（v7？）。
2. JBoss应用服务器（V7？）只用JBoss的螺纹
3. 纯Java 5的任务执行框架（的ThreadPoolExecutor）

可以在这些选项的利弊有人评论。

在一个侧面说明，我也喜欢下面的相关考虑

• 关于IBM /孙JDK到底是如何管理做出最好的多核心处理器的各自优点。我打算运行在IBM或Sun java上，运行jvm。
• 无论JBoss是否使用java 5线程模型（以及从哪个版本开始）。

编辑 Enno Shioji回答的几句话。

1. JBoss在图片中的原因是因为存储在数据库中的数据通过webapp提供。这样我的客户可能会问“为什么文件解析不在AS中？”。
2. 我同意这个过程可能是IO绑定而不是CPU绑定。然而，我急于避免的情况是，在整个os/pthread/jvm/javalib多层香草片中，糟糕的线程调度逻辑会减慢传入文件的获取速度。

Answer 1

JBoss AS只是一个应用服务器。除非你想使用它的服务（比如JMS，WS，EJB，JPA等），否则你根本不想涉及到JBoss。这只会让事情变得复杂而且可能会变慢。

根据你想要做什么，使用Quartz可能是一个好主意。这不是因为性能 - 只是因为它可能会让你的实现更容易。如果你的应用程序在功能上很简单，只要使用ThreadPoolExecutor就可以了（并且和JVM上的一样）。

除非您在分析文件时进行了非常繁重的数字处理，否则CPU不会成为您的应用程序的瓶颈。我的（疯狂的）赌注就是数据库访问。因此，除非您测试应用程序，否则我不担心CPU效率（或应用程序的JVM运行情况）。并确定这是一个瓶颈。

UPDATE：
噢好的。在这种情况下，我的建议是使用EJB定时器进行定期检查，EJB定时器使用Message Driven Bean或EJB 3.1中添加的新轻量级异步服务向JMS提交消息/作业。只要你这样做（而不是自己产生一堆​​线程等）。），我真的不会担心线程调度问题，因为JBoss会负责正确的线程设计（主要有多少线程产生以及如何在任务之间共享等）。除非你测试并发现它没有足够的性能，否则你可能首先试着让Timer做所有的工作（而不是使用花哨的JMS和MDB /异步服务的东西）。这样比较简单，而且通常具有足够的性能。

几乎所有的线程调度问题都来自不好的并发设计（即程序员的错误）。除非你正在调整CPU密集型并行计算或类似的东西，否则我真的不用担心JVM的调度机制。这就好像担心，如果你将要用实验设备从那里做一次蹦极跳，那么这座桥是否会保持住......（你想先担心设备）