目录
Quartz的架构是模块化的，因此为了让它运行，需要将几个组件“拼接”在一起。幸运的是，有一些助手可以实现这一目标。
在Quartz可以完成其工作之前需要配置的主要组件是：
- ThreadPool 线程池
- JobStore Job存储
- DataSources (if necessary) 如果有必要
- The Scheduler itself 调度器本身
ThreadPool提供了一组线程供Quartz在执行作业时使用。池中的线程越多，可以并发运行的作业就越多。但是，太多的线程可能会阻塞您的系统。大多数Quartz用户发现，5个左右的线程是足够的——因为它们在任何给定的时间内都少于100个作业，作业通常不会同时运行，而且作业是短暂的(快速完成)。其他用户发现他们需要10个、15个、50个甚至100个线程——因为他们有成千上万个具有不同时间表的触发器——这些触发器在任何给定的时刻平均要执行10到100个作业。为调度器的池找到合适的大小完全取决于您使用调度器的用途。除了尽可能地减少线程的数量(为了您的机器的资源)之外，没有真正的规则——但是请确保您有足够的线程供您的作业准时启动。注意，如果触发的时间到了，并且没有可用的线程，Quartz会阻塞(暂停)直到一个线程可用，然后任务会执行——比它应该执行的时间晚了一些毫秒。这甚至可能导致线程失火——如果在调度程序配置的“未触发阈值”期间没有可用线程的话。
ThreadPool接口在org.quartz.spi包中定义，您可以以任何您喜欢的方式创建ThreadPool实现。Quartz附带了一个名为org.quartz.simpl.SimpleThreadPool的简单（但非常令人满意）的线程池。这个ThreadPool只是在它的池中维护一组固定的线程 - 永不增长，永不收缩。但它非常强大并且经过了很好的测试 - 几乎所有使用Quartz的人都使用这个池。
JobStores和 DataSources在本教程的第9课中进行了讨论。值得注意的是，所有JobStores都实现了org.quartz.spi.JobStore接口 - 如果其中一个捆绑的JobStore不能满足您的需求，那么您可以创建自己的。
最后，您需要创建Scheduler实例。需要为Scheduler本身指定一个名称，告知其RMI设置，并传递JobStore和ThreadPool的实例。RMI设置包括调度程序是否应将自身创建为RMI的服务器对象（使其自身可用于远程连接），要使用的主机和端口等等.stdrequerfactory(下面讨论)还可以生成调度程序实例，它们实际上是在远程进程中创建的调度程序的代理(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）它不允许声明式配置——换句话说，您最终会硬编码所有调度器的设置。
Logging ：日志
Quartz使用SLF4J框架满足其所有日志记录需求。为了“调整”日志记录设置（例如输出量以及输出的位置），您需要了解SLF4J框架，这超出了本文档的范围。
如果您希望获取有关trigger firings 和job executions 额外的信息，你可能有兴趣 对 org.quartz.plugins.history.LoggingJobHistoryPlugin和/或 org.quartz.plugins.history.LoggingTriggerHistoryPlugin。