配置、资源使用和调度器工厂

Quartz的架构是模块化的，因此要使其运行，需要将几个组件“卡”在一起。幸运的是，有一些帮助者可以实现这一点。

Quartz工作前需要配置的主要组件有：

• 线程池【ThreadPool】

• 作业存储【JobStore】

• 数据源【DataSources】（如有必要）

• 调度器【Scheduler】本身

线程池提供了一组线程供Quartz在执行作业时使用。池中的线程越多，可以同时运行的作业数就越多。然而，过多的线程可能会使系统陷入停滞。大多数Quartz用户发现大约5个线程是足够的——因为他们在任何给定的时间都少于100个作业，这些作业通常不会同时运行，而且这些作业很短（很快完成）。其他用户发现，他们需要10个、15个、50个甚至100个线程，因为他们有数以万计的触发器和不同的时间表，最终平均有10到100个作业试图在任何给定的时刻执行。为调度程序池找到合适的大小完全取决于使用调度程序的目的。除了尽可能减少线程数量（为了机器的资源）之外，没有什么规则，但是要确保你有足够的资源让你的作业按时启动。注意，如果触发器的触发时间到达，并且没有可用的线程，Quartz将阻塞（暂停），直到线程可用，然后作业将执行——比应有的时间晚一些毫秒。如果在调度程序配置的“无触发阈值”期间没有可用线程，这甚至可能导致线程无触发。

线程池接口在org.quartz.spi包中定义，您可以以任何方式创建ThreadPool实现。Quartz附带一个名为org.quartz.simpl.SimpleThreadPool的简单（但非常令人满意）线程池。这个线程池只是在其池中维护一组固定的线程-从不增长，从不收缩。但它在其它方面非常强大，并且经过了很好的测试——几乎所有使用Quartz的人都使用这个池。

本教程第9课讨论了作业存储JobStores和数据源DataSources。值得注意的是，所有作业存储都实现了org.quartz.spi.JobStore接口——如果其中一个捆绑的作业存储不符合您的需求，那么您可以自己创建。

最后，您需要创建调度器实例。调度器本身需要被赋予一个名称，说明它的RMI设置，并移交作业存储和线程池的实例。RMI设置包括调度器是否应将自身创建为RMI的服务器对象（使其自身可用于远程连接）、要使用的主机和端口等。StdSchedulerFactory（下面讨论）还可以生成实际上是远程进程中创建的调度器的代理（RMI存根）的调度器实例。

StdSchedulerFactory

StdSchedulerFactory是org.quartz.SchedulerFactory接口的一个实现。它使用一组属性（java.util.properties）来创建和初始化Quartz调度器。属性通常存储在文件中并从文件中加载，但也可以由程序创建并直接交给工厂。只需在工厂上调用getScheduler()，就会生成调度程序，初始化它（及其线程池、作业存储和数据源），并向其公共接口返回句柄。

Quartz发行版的“docs/config”目录中有一些示例配置（包括属性描述）。您可以在Quartz文档的“参考”部分的“配置”手册中找到完整的文档。

DirectSchedulerFactory

DirectSchedulerFactory是另一个SchedulerFactory实现。对于那些希望以更编程的方式创建调度器实例的人来说，它非常有用。由于以下原因，通常不鼓励使用它：

(1)它要求用户对他们正在做的事情有更深入的了解。

(2)它不允许声明性配置，或者换句话说，你最终会对调度器的所有设置进行硬编码。

Logging

Quartz使用SLF4J框架满足其所有日志记录需求。为了“调整”日志记录设置（例如输出量和输出去向），您需要了解SLF4J框架，这超出了本文档的范围。

如果您想获取有关触发器触发和作业执行的额外信息，您可以去了解org.quartz.plugins.history.LoggingJobHistoryPlugin和org.quartz.plugins.history.LoggingTriggerHistoryPlugin