（翻译）Quartz官方教程——第十课：配置，资源使用和SchedulerFactory

Quartz的架构是模块化的，所以为了让它运行几个组件须要“拼凑”在一块儿。幸运的是，有一些类能够帮助你作到这一点。

在Quartz开始工做以前须要配置的主要组件有：

• ThreadPool
• JobStore
• DataSources（若是必要的话）
• Scheduler自己

ThreadPool提供了Quartz执行任务时须要使用的线程。线程池中的线程越多，能够并发执行的任务数就越大。可是，太多的线程可能会让系统崩溃。大多数Quartz用户发现大约5个线程就足够用——由于它们在任什么时候候的任务都不超过100个，并且这些工做一般不会同时运行且运行的很快。其余用户发现他们须要10个、15个、50个甚至100个线程——由于他们有成千上万的触发器且最终每刻大概有10~100个任务同时执行。你的线程池的合适大小彻底取决于你要如何使用调度器。这个没有真正的规则，除了保持尽量小的线程数量（为了节省机器资源）——可是确保你又足够的线程让你的任务去触发运行。请注意，若是触发器的触发时间到了，而且没有可用线程，则Quartz将阻塞（暂停），直到线程可用，而后执行做业——比它应该执行的时间晚数毫秒。这甚至可能致使线程misfire——若是等待时间超过了配置的“misfire threshold”。

ThreadPool接口在org.quartz.spi包中定义，您可使用任何您喜欢的方式建立ThreadPool实现。Quartz附带一个简单的（但很是使人满意的）名为org.quartz.simpl.SimpleThreadPool的线程池。这个ThreadPool只是在其池中维护一组固定的线程 - 永远不会增加，永远不会缩小。但它是至关强大的，而且通过很好的测试 - 几乎每一个使用Quartz的人都使用这个池。

JobStores和DataSources在课程9中讨论过。值得一提的是，全部JobStore都实现了org.quartz.spi.JobStore接口 - 若是其中一个捆绑的JobStore不适合您的需求，那么您能够本身建立。

最后，你须要建立你的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文档的“Reference”部分的“Configuration”手册中找到完整的文档。

DirectSchedulerFactory

DirectSchedulerFactory是另外一个SchedulerFactory实现。对于那些但愿以更加程序化的方式建立其调度程序实例的人来讲很是有用。但因为如下缘由，一般不鼓励使用它：（1）它要求用户必须很明确它们本身在作什么，（2）它不容许进行声明式配置 - 或者换句话说，您最终会对全部调度程序的设置进行硬编码。

Logging

Quartz使用SLF4J框架知足全部的日志需求。为了“调整”日志设置（例如输出量和输出位置），您须要了解SLF4J框架，这超出了本文的范围。

若是您想捕获关于触发触发和做业执行的额外信息，您可能有兴趣启用org.quartz.plugins.history.LoggingJobHistoryPlugin

和/或org.quartz.plugins.history.LoggingTriggerHistoryPlugin