（翻譯）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