前言

現(xiàn)代的應用程序早已不是以前的那些由簡單的增刪改查拼湊而成的程序了，高復雜性早已是標配，而任務的定時調(diào)度與執(zhí)行也是對程序的基本要求了。

很多業(yè)務需求的實現(xiàn)都離不開定時任務，例如，每月一號，移動將清空你上月未用完流量，重置套餐流量，以及備忘錄提醒、鬧鐘等功能。

java 系統(tǒng)中主要有三種方式來實現(xiàn)定時任務：

• timer和timertask
• scheduledexecutorservice
• 三方框架 quartz

下面我們一個個來看。

timer和timertask

先看一個小 demo，接著我們再來分析其中原理：

這種方式的定時任務主要用到兩個類，timer 和 timertask。其中，timertask 繼承接口 runnable，抽象的描述一種任務類型，我們只要重寫實現(xiàn)它的 run 方法就可以實現(xiàn)自定義任務。

而 timer 就是用于定時任務調(diào)度的核心類，demo 中我們調(diào)用其 schedule 并指定延時 1000 毫秒，所以上述代碼會在一秒鐘后完成打印操作，接著程序結束。

那么，使用上很簡單，兩個步驟即可，但是其中的實現(xiàn)邏輯是怎樣的呢？

timer 接口

首先，timer 接口中，這兩個字段是非常核心重要的：

taskqueue 是一個隊列，內(nèi)部由動態(tài)數(shù)組實現(xiàn)的最小堆結構，換句話說，它是一個優(yōu)先級隊列。而優(yōu)先級參考下一次執(zhí)行時間，越快執(zhí)行的越排在前面，這一點我們回頭再研究。

接著，這個 timerthread 類其實是 timer 的一個內(nèi)部類，它繼承了 thread 并重寫了其 run 方法，該線程實例將在構建 timer 實例的時候被啟動。

run 方法內(nèi)部會循環(huán)的從隊列中取任務，如果沒有就阻塞自己，而當我們成功的向隊列中添加了定時任務，也會嘗試喚醒該線程。

我們也來看一下 timer 的構造方法：

再簡單不過的構造函數(shù)了，為內(nèi)部線程設置線程名，并啟動該線程。

最后，我們著重看一下 timer 中用于配置一個定時任務進任務隊列的方法。

相信有了注釋，這幾個方法的區(qū)別與作用應該不難理解，但是其中有兩個概念需要作一點區(qū)分。

==固定延時== vs ==固定頻率==

固定延時：以任務的上一次 實際 執(zhí)行時間做參考，往后延時 period 毫秒。

固定頻率：任務的往后每一次執(zhí)行時間都在任務提交的那一刻得到了確定，不論你上次任務是否意外延時了，定時定點執(zhí)行下一次任務。

這兩者的區(qū)別還是很大的，希望你能夠理解清楚，接著我們以其中一個方法為例，看看底層實現(xiàn)。

以這個方法為例，其他重載方法的底層調(diào)用都是同樣的，我們不去贅述。

這個方法的作用，我們再說一遍。

以當前時間為準，延時 delay 毫秒后第一次執(zhí)行該任務，并且采取固定延時的方式，每隔 period 毫秒再次執(zhí)行該任務。

開頭的兩個異常判斷我們不再贅述，看看 sched 方法：

方法需要傳入三個參數(shù)，參數(shù) task 代表的需要執(zhí)行的任務體，timertask 我們回頭會詳細介紹，這里你知道它代表了一個任務體即可。

參數(shù) time 描述了該任務下一次執(zhí)行的時刻，計算機底層是以毫秒描述時刻的，所以這里轉(zhuǎn)換為 long 類型來描述時刻。

參數(shù) period 是固定延時的毫秒數(shù)。

整個方法的邏輯我們可以總結概括一下，具體的代碼就不一行行分析了，因為也不難。

1. 首先使用任務隊列的內(nèi)置對象鎖，鎖住個隊列。
2. 接著再去鎖住我們的 task，并修改其內(nèi)部的一些屬性字段值，nextexecutiontime 指明下一次任務執(zhí)行時間，period 設置固定延時的毫秒數(shù)，修改 state 狀態(tài)為計劃中。
3. 然后將 task 添加到任務隊列，其中 add 方法內(nèi)部會進行最小堆重構，參考的就是 nextexecutiontime 字段的值，越小優(yōu)先級越高。
4. 判斷如果自己就是隊列第一個任務，那么將喚醒 timer 中阻塞了的任務線程。

可能會有人疑問，timer 如何判斷一個任務是否是重復執(zhí)行的，還是單次執(zhí)行就結束的？

答案在 timerthread 的 run 方法里，有興趣你可以去研究下，方法體比較多比較長，這里不做分析。

當我們構造 timer 實例的時候，就會啟動該線程，該線程會在一個死循環(huán)中嘗試從任務隊列上獲取任務，如果成功獲取就執(zhí)行該任務并在執(zhí)行結束之后做一個判斷。

如果 period 值為零，則說明這是一次普通任務，執(zhí)行結束后將從隊列首部移除該任務。

如果 period 為負值，則說明這是一次固定延時的任務，修改它下次執(zhí)行時間 nextexecutiontime 為當前時間減去 period，重構任務隊列。

如果 period 為正數(shù)，則說明這是一次固定頻率的任務，修改它下次執(zhí)行時間為 上次執(zhí)行時間加上 period，并重構任務隊列。

其實，我也已經(jīng)把 timerthread 的 run 方法里最核心的邏輯也已經(jīng)介紹了，建議大家親自去研究研究具體代碼的實現(xiàn)，你會對這一塊的邏輯更清晰。

最后，我們看一看這個 timer 它有哪些劣勢的地方：

• timer 的背后只有一個線程，不管你有多少個任務，都只有一個工作線程，效率上必然是要打折扣的。
• 限于單線程，如果第一個任務邏輯上死循環(huán)了，后續(xù)的任務一個都得不到執(zhí)行。
• 依然是由于單線程，任一任務拋出異常后，整個 timer 就會結束，后續(xù)任務全部都無法執(zhí)行。

所以你看，單線程的 timer 帶來了太多局限性，于是我們看它的替代者。

ps：本來計劃再介紹下 timertask 這個抽象任務類的，但是發(fā)現(xiàn)實在沒啥好介紹的，就是增加了兩個字段，一個用于記錄下一次該任務的執(zhí)行時間，一個用于延時毫秒數(shù)。你也只需要重寫其 run 方法即可。

scheduledexecutorservice

這個接口相信你一定眼熟，我告訴你在哪見過。

你看，它是我們異步框架中的接口，正好我們今天來介紹他，這樣整個異步框架中所有的接口我們都分析過了。

scheduledexecutorservice中定義的這四個接口方法和 timer 中對應的方法幾乎一樣，只不過 timer 的 scheduled 方法需要在外部傳入一個 timertask 的抽象任務。

而我們的 scheduledexecutorservice 封裝的更加細致了，隨便你傳 runnable 或是 callable，我會在內(nèi)部給你做一層封裝，封裝一個類似 timertask 的抽象任務類（scheduledfuturetask）。

然后傳入線程池，啟動線程去執(zhí)行該任務，而我們的 scheduledfuturetask 重寫的 run 方法是這樣的：

如果 periodic 為 true 則說明這是一個需要重復執(zhí)行的任務，否則說明是一個一次性任務。

所以實際執(zhí)行該任務的時候，需要分類，如果是普通的任務就直接調(diào)用 run 方法執(zhí)行即可，否則在執(zhí)行結束之后還需要重置下下一次執(zhí)行時間。

整體來說，scheduledexecutorservice 區(qū)別于 timer 的地方就在于前者依賴了線程池來執(zhí)行任務，而任務本身會判斷是什么類型的任務，需要重復執(zhí)行的在任務執(zhí)行結束后會被重新添加到任務隊列。

而對于后者來說，它只依賴一個線程不停的去獲取隊列首部的任務并嘗試執(zhí)行它，無論是效率上、還是安全性上都比不上前者。

所以，建議使用 scheduledexecutorservice 取代 timer，當然，通過學習 timer 會更有助于對 scheduledexecutorservice 的研究。

三方框架 quartz

除了上述兩種定時任務框架外，java 生態(tài)圈還存在一種開源的三方框架，他就是 quartz。

quartz 是一個功能完善的任務調(diào)度框架，支持集群環(huán)境下的任務調(diào)度，需要將任務調(diào)度狀態(tài)序列化到數(shù)據(jù)庫。

quartz 已經(jīng)是隨著分布式概念的流行，成為企業(yè)級定時任務調(diào)度框架中的不二選擇。

quartz 這個框架的使用及與原理在本篇就不做介紹了，我們會在后續(xù)介紹分布式概念的時候再來介紹它與 springcloud 平臺下的整合使用情況。

總結

以上就是這篇文章的全部內(nèi)容了，希望本文的內(nèi)容對大家的學習或者工作具有一定的參考學習價值，如果有疑問大家可以留言交流，謝謝大家對服務器之家的支持。

原文鏈接：https://www.cnblogs.com/yangming1996/p/10317949.html