Quartz以模块方式构架，因此，要使它运行，几个组件必须很好的咬合在一起。幸运的是，已经有了一些现存的助手可以完成这些工作。
在Quartz进行工作之前需要被配置的组件主要有：
• ThreadPool 线程池
• JobStore
• DataSources (如果需要)
• Scheduler本身
ThreadPool（线程池）为Quartz运行任务时提供了一些线程。池中的线程越多，那么并发运行的任务数就越多。但是，过多的线程会降低系统的运行速度。大多数用户发现5个或者相近的线程就已经足够了，因为任何给定的时间段内都不超过100个任务要运行，而且这些任务不会在同一时刻运行，同时任务活动时间很短（很快就结束了）。其他的用户发现需要10，15，50，甚至100个线程，因为每个schedules都有成千上万的触发器，并且在给定的时刻会有平均10到100个任务在运行。确定schedule的线程池中的线程数量的合理值取决于用scheduler来做什么。除了尽可能少地设置线程数量，使得任务执行时线程够用外（由于计算机资源的有限性），没有其他实用的准则。注意：如果触发器触发的时间到了，却没有可用的线程，那么Quartz将会让这个任务等待，直到有线程可用。这样，任务的执行将比它因该执行的时间晚一些毫秒。如果scheduler的配置的“未触发极限”时限中仍然没有线程可用，这甚至会导致“未触发(misfire)”。
ThreadPool接口定义在org.quartz.spi中，你也可以创建一个自己的ThreadPool（线程池）实现，Quartz打包了一个简单（但非常满意的）的线程池，名为：org.quartz.simpl.SimpleThreadPool，这个线程池只是简单地在它的池中保持固定数量的线程，不增长也不缩小。但是它非常健壮且经过良好的测试，差不多每个Quartz用户都使用这个池。
JobStores和DataSrouces在第九课中已经讨论过，值得注意的一个事实是所有的JobStores都实现了IJobStore接口，如果捆绑的JobStores不能满足你的要求，你可以自己开发一个。
JobStores
最后你需要创建自己的Scheduler实例。Scheduler本身需要给定一个名字处理的JobStore和ThreadPool实例。
StdSchedulerFactory
StdSchedulerFactory是对org.quartz.SchedulerFactory接口的一个实现。是使用一套属性(NameValueCollection)来创建和初始化Quartz Scheduler。这些属性通常在文件中存储和加载。也可以通过编写程序来直接操作工厂。简单地调用工厂的getScheduler()就可以产生一个scheduler，初始化（以及它的ThreadPool、JobStore和DataSources），并且返回一个公共的接口。
DirectSchedulerFactory
DirectSchedulerFactory是SchedulerFactory的另一个实现。它对于那些希望用更加程序化的方式创建Scheduler非常有用。不鼓励使用它的原因如下：
(1) 它需要用户非常了解他们想要干什么。
(2) 它不允许声明式的配置。换句话说，它使用硬编码的方式设置scheduler。
Logging 日志
Quartz用Common.Logging framework架来满足它所有的日志需要。Quartz不会产生太多的日志信息，通常只是一些初始化信息以及只有在任务执行时发生的一些严重问题的信息。要“调整”日志设置（例如输出量以及在哪输出），需要理解Common.Logging framework框架，这不在本文档的讨论范围内。
本文转自 张善友 51CTO博客，原文链接：http://blog.51cto.com/shanyou/73986，如需转载请自行联系原作者