java - JBoss 线程模型与 Java 5 任务执行框架

Question

我需要用java开发一个简单的守护进程，它从文件夹中获取文件，分析它们的内容并将一些信息存储在数据库中。不可避免地会出现突发的 Activity (例如，当恶魔没有运行时文件已经累积)，我正在寻找最有效的线程模型来尽快处理这些积压的工作。

我目前正在考虑几种选择。

1. 带有 Quartz 的 JBoss AS(v7？)。
2. JBoss AS(v7？)仅具有 JBoss 线程
3. 纯java 5任务执行框架(ThreadPoolExecutor)

有人可以评论一下这些选项的优缺点吗？

顺便说一句，我也对以下相关考虑感兴趣

• 关于 IBM/Sun JDK 如何真正充分利用多核处理器的各自优点。我计划在 IBM 或 Sun java 7 jvm 上运行。
• JBoss 是否使用(以及从哪个版本开始)Java 5 线程模型。

编辑在Enno Shioji的善意回答之后的一些评论。

1. 图中之所以是 JBoss，是因为存储在 DB 中的数据是通过 Web 应用程序提供的。这样我的客户可能会问“为什么文件解析不在AS中？”。
2. 我同意该进程可能受 IO 限制而不是 CPU 限制。然而，我渴望避免的是整个 os/pthread/jvm/javalib 多层普通切片中糟糕的线程调度逻辑会减慢传入文件的获取速度。

Answer 1

JBoss AS 只是一个应用服务器。除非您想使用它的服务(如 JMS、WS、EJB、JPA 等)，否则您根本不想涉及 JBoss。这只会使事情变得复杂并且可能会更慢。

使用 Quartz 可能是一个好主意，具体取决于您想要做什么。但这并不是因为性能——只是因为它可能会让您的实现变得更容易。如果您的应用程序功能简单，则只需使用 ThreadPoolExecutor 就可以了(并且与 JVM 上的性能一样好)。

除非您在分析文件时进行了大量的数字运算，否则 CPU 不会成为应用程序的瓶颈。我(疯狂)打赌这将是数据库访问。因此，除非您测试应用程序，否则我不会担心 CPU 效率(或应用程序运行的 JVM)。并确定这是一个瓶颈。

更新:
哦好的。在这种情况下，我的建议是使用 EJB 计时器进行定期检查，该计时器使用消息驱动 Bean 或 EJB 3.1 中添加的新轻量级异步服务将消息/作业提交到 JMS。只要你这样做(而不是自己生成一堆线程等)，我真的不会担心线程调度，因为 JBoss 会负责正确的线程设计(主要是生成多少个线程以及如何生成线程)在任务之间共享它们等)。

事实上，您可能希望首先尝试让 Timer 完成所有工作(而不是使用带有 MDB/异步服务内容的精美 JMS)，除非您测试并发现它执行得不够。这更简单，而且通常性能足够。

几乎所有线程调度问题都源于糟糕的并发设计(即程序员的错误)。除非你正在微调 CPU 密集型并行计算或类似的东西，否则我真的不会担心 JVM 的调度机制。这就像当你准备用实验设备从那里进行蹦极时担心桥是否会保持住一样......(你想首先担心设备)