Configuration, Resource Usage and SchedulerFactory

Quartz的架构是模块化的，因此要让它运行几个组件，需要将其“断开”。幸运的是，存在一些帮助实现这种情况的助手。

在Quartz能够完成其工作之前，需要配置的主要组件是:

• ThreadPool
• JobStore
• DataSources (if necessary)
• The Scheduler itself

ThreadPool

ThreadPool提供了一组用于执行作业时使用 Quartz 的线程。池中线程越多，可以并发运行的作业数量就越多。但是，太多的线程可能会使系统崩溃。

大多数 Quartz 用户发现，5个左右的线程足够多——因为在任何给定的时间内，他们的工作岗位都少于100个，而这些工作通常不会同时运行，而且工作时间很短(完成得很快)。其他用户发现他们需要10个、15个、50个甚至100个线程——因为他们有成千上万个不同时间表的触发点——在任何给定的时刻，他们平均要执行10到100个任务。为调度器的池找到合适的大小完全取决于您使用调度器的用途。除了保持线程数量尽可能小(为了您的机器的资源)之外，没有真正的规则，但是要确保您有足够的时间让您的工作按时启动。请注意，如果触发的触发时间到达，并且没有可用的线程，Quartz将阻塞(暂停)，直到有一个线程可用，然后任务将执行——比它应该执行的时间晚几毫秒。这甚至可能导致线程失火(MisFire)——如果调度程序配置的“misfire阈值”(misfire threshold)的持续时间没有可用线程的话。

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

JobStores & DataSources

值得注意的是，所有的jobstore都实现了 org.quartz.spi.JobStore 接口——如果其中一个绑定的JobStore不符合您的需求，那么您可以自己创建。

Scheduler

调度程序本身需要给定一个名称，告诉它的RMI设置，以及一个JobStore和ThreadPool的实例。

RMI设置包括:调度器是否应该创建自己作为RMI的服务器对象(使自己可以用于远程连接)、主机和端口的使用等。StdSchedulerFactory (下面讨论)也可以生成调度实例，它们实际上是远程进程中创建的调度程序的代理(RMI存根)。

StdSchedulerFactory

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

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

DirectSchedulerFactory

DirectSchedulerFactory 是另一个调度程序工厂实现。
对于那些希望以更程序化的方式创建调度实例的人来说，这是很有用的。

它的使用通常是由于以下原因而被阻止的:

(1)它要求用户对他们正在做的事情有一个更大的理解，

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

Logging

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

如果你想获取额外信息触发解雇和执行工作,org.quartz.plugins.history.LoggingJobHistoryPlugin & org.quartz.plugins.history.LoggingTriggerHistoryPlugin