配置，资源使用和SchedulerFactory

quartz的架构是模块化的，因此要运行几个组件需要“快速”在一起。幸运的是，有一些帮手出现这种情况。

在Quartz可以完成其工作之前需要配置的主要组件有：

• 线程池
• JobStore
• DataSources（如有必要）
• 计划程序本身

该线程池提供了一组Quartz在执行jobs时使用的线程。池中的线程越多，并发运行的jobs数越多。但是，太多的线程可能会破坏您的系统。大多数Quartz用户发现，5个左右的线程是充足的 - 因为在任何给定时间，它们的jobs数量少于100个，通常不会同时运行这些jobs，而且这些jobs是短暂的（快速完成）。其他用户发现他们需要10个，15个，50个甚至100个线程，因为它们具有数万个具有各种计划的triggers，最终平均在任何给定时刻执行10到100个jobs。为调度程序的池找到正确的大小完全取决于您正在使用的调度程序。没有真正的规则，除了保持线程数量尽可能小（为了您的机器的资源） - 但确保您已足够让您的Jobs按时启动。请注意，如果triggers的触发时间到达，并且没有可用的线程，Quartz将阻止（暂停）直到线程可用，然后jobs将执行 - 比它应有的数毫秒。这甚至可能导致线程失火 - 如果在调度程序配置的“失火阈值”的持续时间内没有可用的线程。那么jobs将执行 - 比它应该有几毫秒。

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

JobStores和 DataSource在本教程的第9课中讨论过。值得注意的是，所有JobStores都实现了org.quartz.spi.JobStore接口 - 如果一个捆绑的JobStores不符合您的需求，那么您可以自己创建。

最后，您需要创建您的Scheduler实例。调度程序本身需要被赋予一个名字，告诉其RMI设置，并递交JobStore和ThreadPool的实例。RMI设置包括调度程序是否应将自身创建为RMI的服务器对象（使其可用于远程连接），要使用的主机和端口等。StdSchedulerFactory（下面将讨论）还可以生成实际代理的Scheduler实例（ RMI存根）到在远程进程中创建的计划程序。

StdSchedulerFactory

StdSchedulerFactory是org.quartz.SchedulerFactory接口的一个实现。它使用一组属性（java.util.Properties）来创建和初始化Quartz Scheduler。属性通常存储在文件中并从文件中加载，但也可以由程序创建并直接传递到工厂。简单地调用工厂中的getScheduler（）将生成调度程序，并初始化它（和它的ThreadPool，JobStore和DataSources）并返回一个句柄到它的公共接口。

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

DirectSchedulerFactory

DirectSchedulerFactory是另一个SchedulerFactory实现。对于希望以更加程序化的方式创建其Scheduler实例的用户是有用的。通常不鼓励使用它的用法，原因如下：（1）要求用户更好地了解他们正在做什么，（2）它不允许声明性配置 - 换句话说，你最终会硬 - 编辑所有调度程序的设置。

记录

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

如果要捕获关于triggers启动和jobs执行的额外信息，可能有兴趣启用org.quartz.plugins.history.LoggingJobHistoryPlugin和/或 org.quartz.plugins.history.LoggingTriggerHistoryPlugin。