Timer與TimerTask

其實(shí)就Timer來(lái)講就是一個(gè)調(diào)度器,而TimerTask呢只是一個(gè)實(shí)現(xiàn)了run方法的一個(gè)類(lèi),而具體的TimerTask需要由你自己來(lái)實(shí)現(xiàn),例如這樣:

Timer timer = new Timer(); timer.schedule(new TimerTask() { public void run() { System.out.println("abc"); } }, 200000 , 1000);

這里直接實(shí)現(xiàn)一個(gè)TimerTask(當(dāng)然，你可以實(shí)現(xiàn)多個(gè)TimerTask，多個(gè)TimerTask可以被一個(gè)Timer會(huì)被分配到多個(gè)Timer中被調(diào)度，后面會(huì)說(shuō)到Timer的實(shí)現(xiàn)機(jī)制就是說(shuō)內(nèi)部的調(diào)度機(jī)制)，然后編寫(xiě)run方法，20s后開(kāi)始執(zhí)行，每秒執(zhí)行一次，當(dāng)然你通過(guò)一個(gè)timer對(duì)象來(lái)操作多個(gè)timerTask，其實(shí)timerTask本身沒(méi)什么意義，只是和timer集合操作的一個(gè)對(duì)象，實(shí)現(xiàn)它就必然有對(duì)應(yīng)的run方法，以被調(diào)用，他甚至于根本不需要實(shí)現(xiàn)Runnable，因?yàn)檫@樣往往混淆視聽(tīng)了，為什么呢？也是本文要說(shuō)的重點(diǎn)。

在說(shuō)到timer的原理時(shí)，我們先看看Timer里面的一些常見(jiàn)方法：

public void schedule(TimerTask task, long delay)

這個(gè)方法是調(diào)度一個(gè)task，經(jīng)過(guò)delay(ms)后開(kāi)始進(jìn)行調(diào)度，僅僅調(diào)度一次。

public void schedule(TimerTask task, Date time)

在指定的時(shí)間點(diǎn)time上調(diào)度一次。

public void schedule(TimerTask task, long delay, long period)

這個(gè)方法是調(diào)度一個(gè)task，在delay（ms）后開(kāi)始調(diào)度，每次調(diào)度完后，最少等待period（ms）后才開(kāi)始調(diào)度。

public void schedule(TimerTask task, Date firstTime, long period)

和上一個(gè)方法類(lèi)似，唯一的區(qū)別就是傳入的第二個(gè)參數(shù)為第一次調(diào)度的時(shí)間。

public void scheduleAtFixedRate(TimerTask task, long delay, long period)

調(diào)度一個(gè)task，在delay(ms)后開(kāi)始調(diào)度，然后每經(jīng)過(guò)period(ms)再次調(diào)度

貌似和方法：schedule是一樣的，其實(shí)不然，后面你會(huì)根據(jù)源碼看到，schedule在計(jì)算下一次執(zhí)行的時(shí)間的時(shí)候，是通過(guò)當(dāng)前時(shí)間（在任務(wù)執(zhí)行前得到） + 時(shí)間片

而scheduleAtFixedRate方法是通過(guò)當(dāng)前需要執(zhí)行的時(shí)間（也就是計(jì)算出現(xiàn)在應(yīng)該執(zhí)行的時(shí)間）+ 時(shí)間片，前者是運(yùn)行的實(shí)際時(shí)間，而后者是理論時(shí)間點(diǎn)

例如：schedule時(shí)間片是5s，那么理論上會(huì)在5、10、15、20這些時(shí)間片被調(diào)度，但是如果由于某些CPU征用導(dǎo)致未被調(diào)度，假如等到第8s才被第一次調(diào)度，那么schedule方法計(jì)算出來(lái)的下一次時(shí)間應(yīng)該是第13s而不是第10s，這樣有可能下次就越到20s后而被少調(diào)度一次或多次

而scheduleAtFixedRate方法就是每次理論計(jì)算出下一次需要調(diào)度的時(shí)間用以排序，若第8s被調(diào)度，那么計(jì)算出應(yīng)該是第10s

所以它距離當(dāng)前時(shí)間是2s，那么再調(diào)度隊(duì)列排序中，會(huì)被優(yōu)先調(diào)度，那么就盡量減少漏掉調(diào)度的情況。

public void scheduleAtFixedRate(TimerTask task, Date firstTime,long period)

方法同上，唯一的區(qū)別就是第一次調(diào)度時(shí)間設(shè)置為一個(gè)Date時(shí)間，而不是當(dāng)前時(shí)間的一個(gè)時(shí)間片，我們?cè)谠创a中會(huì)詳細(xì)說(shuō)明這些內(nèi)容。

接下來(lái)看源碼

源碼

首先看Timer的構(gòu)造方法有幾種：

構(gòu)造方法1：

無(wú)參構(gòu)造方法，簡(jiǎn)單通過(guò)Tiemer為前綴構(gòu)造一個(gè)線程名稱(chēng)：

public Timer() { this("Timer-" + serialNumber()); }

傳入是否為后臺(tái)線程，如果設(shè)置為后臺(tái)線程，則主線程結(jié)束后，timer自動(dòng)結(jié)束，而無(wú)需使用cancel來(lái)完成對(duì)timer的結(jié)束

構(gòu)造方法2：

傳入了是否為后臺(tái)線程，后臺(tái)線程當(dāng)且僅當(dāng)進(jìn)程結(jié)束時(shí)，自動(dòng)注銷(xiāo)掉。

public Timer(boolean isDaemon) { this("Timer-" + serialNumber(), isDaemon); }

另外兩個(gè)構(gòu)造方法負(fù)責(zé)傳入名稱(chēng)和將timer啟動(dòng)：

public Timer(String name, boolean isDaemon) { thread.setName(name); thread.setDaemon(isDaemon); thread.start(); }

這里有一個(gè)thread，這個(gè)thread很明顯是一個(gè)線程，被包裝在了Timer類(lèi)中，我們看下這個(gè)thread的定義是：

private TimerThread thread = new TimerThread(queue);

而定義TimerThread部分的是：

class TimerThread extends Thread {<!--{C}%3C!%2D%2D%20%2D%2D%3E-->

看到這里知道了，Timer內(nèi)部包裝了一個(gè)線程，用來(lái)做獨(dú)立于外部線程的調(diào)度，而TimerThread是一個(gè)default類(lèi)型的，默認(rèn)情況下是引用不到的，是被Timer自己所使用的。

接下來(lái)看下有那些屬性

除了上面提到的thread，還有一個(gè)很重要的屬性是：

private TaskQueue queue = new TaskQueue();

看名字就知道是一個(gè)隊(duì)列，隊(duì)列里面可以先猜猜看是什么，那么大概應(yīng)該是我要調(diào)度的任務(wù)吧，先記錄下了，接下來(lái)繼續(xù)向下看：

里面還有一個(gè)屬性是：threadReaper，它是Object類(lèi)型，只是重寫(xiě)了finalize方法而已，是為了垃圾回收的時(shí)候，將相應(yīng)的信息回收掉，做GC的回補(bǔ)，也就是當(dāng)timer線程由于某種原因死掉了，而未被cancel，里面的隊(duì)列中的信息需要清空掉，不過(guò)我們通常是不會(huì)考慮這個(gè)方法的，所以知道java寫(xiě)這個(gè)方法是干什么的就行了。

接下來(lái)看調(diào)度方法的實(shí)現(xiàn)：

對(duì)于上面6個(gè)調(diào)度方法，我們不做一一列舉，為什么等下你就知道了：

來(lái)看下方法：

public void schedule(TimerTask task, long delay)

的源碼如下：

public void schedule(TimerTask task, long delay) { if (delay < 0) throw new IllegalArgumentException("Negative delay."); sched(task, System.currentTimeMillis()+delay, 0); }

這里調(diào)用了另一個(gè)方法，將task傳入，第一個(gè)參數(shù)傳入System.currentTimeMillis()+delay可見(jiàn)為第一次需要執(zhí)行的時(shí)間的時(shí)間點(diǎn)了（如果傳入Date，就是對(duì)象.getTime()即可，所以傳入Date的幾個(gè)方法就不用多說(shuō)了），而第三個(gè)參數(shù)傳入了0，這里可以猜下要么是時(shí)間片，要么是次數(shù)啥的，不過(guò)等會(huì)就知道是什么了；另外關(guān)于方法：sched的內(nèi)容我們不著急去看他，先看下重載的方法中是如何做的

在看看方法：

public void schedule(TimerTask task, long delay,long period)

源碼為：

public void schedule(TimerTask task, long delay, long period) { if (delay < 0) throw new IllegalArgumentException("Negative delay."); if (period <= 0) throw new IllegalArgumentException("Non-positive period."); sched(task, System.currentTimeMillis()+delay, -period); }

看來(lái)也調(diào)用了方法sched來(lái)完成調(diào)度，和上面的方法唯一的調(diào)度時(shí)候的區(qū)別是增加了傳入的period，而第一個(gè)傳入的是0，所以確定這個(gè)參數(shù)為時(shí)間片，而不是次數(shù)

注意這個(gè)里的period加了一個(gè)負(fù)數(shù)，也就是取反，也就是我們開(kāi)始傳入1000，在調(diào)用sched的時(shí)候會(huì)變成-1000

其實(shí)最終閱讀完源碼后你會(huì)發(fā)現(xiàn)這個(gè)算是老外對(duì)于一種數(shù)字的理解，而并非有什么特殊的意義，所以閱讀源碼的時(shí)候也有這些困難所在。

最后再看個(gè)方法是：

public void scheduleAtFixedRate(TimerTasktask,long delay,long period)

源碼為：

public void scheduleAtFixedRate(TimerTask task, long delay, long period) { if (delay < 0) throw new IllegalArgumentException("Negative delay."); if (period <= 0) throw new IllegalArgumentException("Non-positive period."); sched(task, System.currentTimeMillis()+delay, period); }

唯一的區(qū)別就是在period沒(méi)有取反，其實(shí)你最終閱讀完源碼，上面的取反沒(méi)有什么特殊的意義，老外不想增加一個(gè)參數(shù)來(lái)表示scheduleAtFixedRate，而scheduleAtFixedRate和schedule的大部分邏輯代碼一致，因此用了參數(shù)的范圍來(lái)作為區(qū)分方法，也就是當(dāng)你傳入的參數(shù)不是正數(shù)的時(shí)候

你調(diào)用schedule方法正好是得到scheduleAtFixedRate的功能，而調(diào)用scheduleAtFixedRate方法的時(shí)候得到的正好是schedule方法的功能，呵呵，這些討論沒(méi)什么意義

討論實(shí)質(zhì)和重點(diǎn)：

來(lái)看sched方法的實(shí)現(xiàn)體：

private void sched(TimerTask task, long time, long period) { if (time < 0) throw new IllegalArgumentException("Illegal execution time."); synchronized(queue) { if (!thread.newTasksMayBeScheduled) throw new IllegalStateException("Timer already cancelled."); synchronized(task.lock) { if (task.state != TimerTask.VIRGIN) throw new IllegalStateException( "Task already scheduled or cancelled"); task.nextExecutionTime = time; task.period = period; task.state = TimerTask.SCHEDULED; } queue.add(task); if (queue.getMin() == task) queue.notify(); } }

queue為一個(gè)隊(duì)列，我們先不看他數(shù)據(jù)結(jié)構(gòu)，看到他在做這個(gè)操作的時(shí)候，發(fā)生了同步，所以在timer級(jí)別，這個(gè)是線程安全的，最后將task相關(guān)的參數(shù)賦值，主要包含nextExecutionTime（下一次執(zhí)行時(shí)間），period（時(shí)間片），state（狀態(tài)），然后將它放入queue隊(duì)列中，做一次notify操作，為什么要做notify操作呢？看了后面的代碼你就知道了。

簡(jiǎn)言之，這里就是講task放入隊(duì)列queue的過(guò)程，此時(shí)，你可能對(duì)queue的結(jié)構(gòu)有些興趣，那么我們先來(lái)看看queue屬性的結(jié)構(gòu)TaskQueue：

class TaskQueue { private TimerTask[] queue = new TimerTask[128]; private int size = 0;

可見(jiàn)，TaskQueue的結(jié)構(gòu)很簡(jiǎn)單，為一個(gè)數(shù)組，加一個(gè)size，有點(diǎn)像ArrayList，是不是長(zhǎng)度就128呢，當(dāng)然不是，ArrayList可以擴(kuò)容，它可以，只是會(huì)造成內(nèi)存拷貝而已，所以一個(gè)Timer來(lái)講，只要內(nèi)部的task個(gè)數(shù)不超過(guò)128是不會(huì)造成擴(kuò)容的；內(nèi)部提供了add(TimerTask)、size()、getMin()、get(int)、removeMin()、quickRemove(int)、rescheduleMin(long newTime)、isEmpty()、clear()、fixUp()、fixDown()、heapify()；

這里面的方法大概意思是：

• add(TimerTaskt)為增加一個(gè)任務(wù)
• size()任務(wù)隊(duì)列的長(zhǎng)度
• getMin()獲取當(dāng)前排序后最近需要執(zhí)行的一個(gè)任務(wù)，下標(biāo)為1，隊(duì)列頭部0是不做任何操作的。
• get(inti)獲取指定下標(biāo)的數(shù)據(jù)，當(dāng)然包括下標(biāo)0.
• removeMin()為刪除當(dāng)前最近執(zhí)行的任務(wù)，也就是第一個(gè)元素，通常只調(diào)度一次的任務(wù)，在執(zhí)行完后，調(diào)用此方法，就可以將TimerTask從隊(duì)列中移除。
• quickRmove(inti)刪除指定的元素，一般來(lái)說(shuō)是不會(huì)調(diào)用這個(gè)方法的，這個(gè)方法只有在Timer發(fā)生purge的時(shí)候，并且當(dāng)對(duì)應(yīng)的TimerTask調(diào)用了cancel方法的時(shí)候，才會(huì)被調(diào)用這個(gè)方法，也就是取消某個(gè)TimerTask，然后就會(huì)從隊(duì)列中移除（注意如果任務(wù)在執(zhí)行中是，還是仍然在執(zhí)行中的，雖然在隊(duì)列中被移除了），還有就是這個(gè)cancel方法并不是Timer的cancel方法而是TimerTask，一個(gè)是調(diào)度器的，一個(gè)是單個(gè)任務(wù)的，最后注意，這個(gè)quickRmove完成后，是將隊(duì)列最后一個(gè)元素補(bǔ)充到這個(gè)位置，所以此時(shí)會(huì)造成順序不一致的問(wèn)題，后面會(huì)有方法進(jìn)行回補(bǔ)。
• rescheduleMin(long newTime)是重新設(shè)置當(dāng)前執(zhí)行的任務(wù)的下一次執(zhí)行時(shí)間，并在隊(duì)列中將其從新排序到合適的位置，而調(diào)用的是后面說(shuō)的fixDown方法。

對(duì)于fixUp和fixDown方法來(lái)講，前者是當(dāng)新增一個(gè)task的時(shí)候，首先將元素放在隊(duì)列的尾部，然后向前找是否有比自己還要晚執(zhí)行的任務(wù)，如果有，就將兩個(gè)任務(wù)的順序進(jìn)行交換一下。而fixDown正好相反，執(zhí)行完第一個(gè)任務(wù)后，需要加上一個(gè)時(shí)間片得到下一次執(zhí)行時(shí)間，從而需要將其順序與后面的任務(wù)進(jìn)行對(duì)比下。

其次可以看下fixDown的細(xì)節(jié)為：

private void fixDown(int k) { int j; while ((j = k << 1) <= size && j > 0) { if (j < size && queue[j].nextExecutionTime > queue[j+1].nextExecutionTime) j++; // j indexes smallest kid if (queue[k].nextExecutionTime <= queue[j].nextExecutionTime) break; TimerTask tmp = queue[j]; queue[j] = queue[k]; queue[k] = tmp; k = j; } }

這種方式并非排序，而是找到一個(gè)合適的位置來(lái)交換，因?yàn)椴⒉皇峭ㄟ^(guò)隊(duì)列逐個(gè)找的，而是每次移動(dòng)一個(gè)二進(jìn)制為，例如傳入1的時(shí)候，接下來(lái)就是2、4、8、16這些位置，找到合適的位置放下即可，順序未必是完全有序的，它只需要看到距離調(diào)度部分的越近的是有序性越強(qiáng)的時(shí)候就可以了，這樣即可以保證一定的順序性，達(dá)到較好的性能。

最后一個(gè)方法是heapify，其實(shí)就是將隊(duì)列的后半截，全部做一次fixeDown的操作，這個(gè)操作主要是為了回補(bǔ)quickRemove方法，當(dāng)大量的quickRmove后，順序被打亂后，此時(shí)將一半的區(qū)域做一次非常簡(jiǎn)單的排序即可。

這些方法我們不在說(shuō)源碼了，只需要知道它提供了類(lèi)似于ArrayList的東西來(lái)管理，內(nèi)部有很多排序之類(lèi)的處理，我們繼續(xù)回到Timer，里面還有兩個(gè)方法是：cancel()和方法purge()方法，其實(shí)就cancel方法來(lái)講，一個(gè)取消操作，在測(cè)試中你會(huì)發(fā)現(xiàn)，如果一旦執(zhí)行了這個(gè)方法timer就會(huì)結(jié)束掉，看下源碼是什么呢：

public void cancel() { synchronized(queue) { thread.newTasksMayBeScheduled = false; queue.clear(); queue.notify(); // In case queue was already empty. } }

貌似僅僅將隊(duì)列清空掉，然后設(shè)置了newTasksMayBeScheduled狀態(tài)為false，最后讓隊(duì)列也調(diào)用了下notify操作，但是沒(méi)有任何地方讓線程結(jié)束掉，那么就要回到我們開(kāi)始說(shuō)的Timer中包含的thread為：TimerThread類(lèi)了，在看這個(gè)類(lèi)之前，再看下Timer中最后一個(gè)purge()類(lèi)，當(dāng)你對(duì)很多Task做了cancel操作后，此時(shí)通過(guò)調(diào)用purge方法實(shí)現(xiàn)對(duì)這些cancel掉的類(lèi)空間的回收，上面已經(jīng)提到，此時(shí)會(huì)造成順序混亂，所以需要調(diào)用隊(duì)里的heapify方法來(lái)完成順序的重排，源碼如下：

public int purge() { int result = 0; synchronized(queue) { for (int i = queue.size(); i > 0; i--) { if (queue.get(i).state == TimerTask.CANCELLED) { queue.quickRemove(i); result++; } } if (result != 0) queue.heapify(); } return result; }

那么調(diào)度呢，是如何調(diào)度的呢，那些notify，和清空隊(duì)列是如何做到的呢？我們就要看看TimerThread類(lèi)了，內(nèi)部有一個(gè)屬性是：newTasksMayBeScheduled，也就是我們開(kāi)始所提及的那個(gè)參數(shù)在cancel的時(shí)候會(huì)被設(shè)置為false。

另一個(gè)屬性定義了

    private TaskQueue queue;

也就是我們所調(diào)用的queue了，這下聯(lián)通了吧，不過(guò)這里是queue是通過(guò)構(gòu)造方法傳入的，傳入后賦值用以操作，很明顯是Timer傳遞給這個(gè)線程的，我們知道它是一個(gè)線程，所以執(zhí)行的中心自然是run方法了，所以看下run方法的body部分是：

public void run() { try { mainLoop(); } finally { synchronized(queue) { newTasksMayBeScheduled = false; queue.clear(); // Eliminate obsolete references } } }

try很簡(jiǎn)單，就一個(gè)mainLoop，看名字知道是主循環(huán)程序，finally中也就是必然執(zhí)行的程序?yàn)閷?shù)為為false，并將隊(duì)列清空掉。

那么最核心的就是mainLoop了，是的，看懂了mainLoop一切都懂了：

private void mainLoop() { while (true) { try { TimerTask task; boolean taskFired; synchronized(queue) { // Wait for queue to become non-empty while (queue.isEmpty() && newTasksMayBeScheduled) queue.wait(); if (queue.isEmpty()) break; // Queue is empty and will forever remain; die // Queue nonempty; look at first evt and do the right thing long currentTime, executionTime; task = queue.getMin(); synchronized(task.lock) { if (task.state == TimerTask.CANCELLED) { queue.removeMin(); continue; // No action required, poll queue again } currentTime = System.currentTimeMillis(); executionTime = task.nextExecutionTime; if (taskFired = (executionTime<=currentTime)) { if (task.period == 0) { // Non-repeating, remove queue.removeMin(); task.state = TimerTask.EXECUTED; } else { // Repeating task, reschedule queue.rescheduleMin( task.period<0 ? currentTime - task.period : executionTime + task.period); } } } if (!taskFired) // Task hasn't yet fired; wait queue.wait(executionTime - currentTime); } if (taskFired) // Task fired; run it, holding no locks task.run(); } catch(InterruptedException e) { } } }

可以發(fā)現(xiàn)這個(gè)timer是一個(gè)死循環(huán)程序，除非遇到不能捕獲的異常或break才會(huì)跳出，首先注意這段代碼：

while (queue.isEmpty() &&newTasksMayBeScheduled) ??????????????????????? queue.wait();

循環(huán)體為循環(huán)過(guò)程中，條件為queue為空且newTasksMayBeScheduled狀態(tài)為true，可以看到這個(gè)狀態(tài)其關(guān)鍵作用，也就是跳出循環(huán)的條件就是要么隊(duì)列不為空，要么是newTasksMayBeScheduled狀態(tài)設(shè)置為false才會(huì)跳出，而wait就是在等待其他地方對(duì)queue發(fā)生notify操作，從上面的代碼中可以發(fā)現(xiàn)，當(dāng)發(fā)生add、cancel以及在threadReaper調(diào)用finalize方法的時(shí)候會(huì)被調(diào)用，第三個(gè)我們基本可以不考慮其實(shí)發(fā)生add的時(shí)候也就是當(dāng)隊(duì)列還是空的時(shí)候，發(fā)生add使得隊(duì)列不為空就跳出循環(huán)，而cancel是設(shè)置了狀態(tài)，否則不會(huì)進(jìn)入這個(gè)循環(huán)，那么看下面的代碼：

if (queue.isEmpty()) ?????????break;

當(dāng)跳出上面的循環(huán)后，如果是設(shè)置了newTasksMayBeScheduled狀態(tài)為false跳出，也就是調(diào)用了cancel，那么queue就是空的，此時(shí)就直接跳出外部的死循環(huán)，所以cancel就是這樣實(shí)現(xiàn)的，如果下面的任務(wù)還在跑還沒(méi)運(yùn)行到這里來(lái)，cancel是不起作用的。

接下來(lái)是獲取一個(gè)當(dāng)前系統(tǒng)時(shí)間和上次預(yù)計(jì)的執(zhí)行時(shí)間，如果預(yù)計(jì)執(zhí)行的時(shí)間小于當(dāng)前系統(tǒng)時(shí)間，那么就需要執(zhí)行，此時(shí)判定時(shí)間片是否為0，如果為0，則調(diào)用removeMin方法將其移除，否則將task通過(guò)rescheduleMin設(shè)置最新時(shí)間并排序：

currentTime = System.currentTimeMillis(); executionTime = task.nextExecutionTime; if (taskFired = (executionTime<=currentTime)) { if (task.period == 0) { // Non-repeating, remove queue.removeMin(); task.state = TimerTask.EXECUTED; } else { // Repeating task, reschedule queue.rescheduleMin( task.period<0 ? currentTime - task.period : executionTime + task.period); } }

這里可以看到，period為負(fù)數(shù)的時(shí)候，就會(huì)被認(rèn)為是按照按照當(dāng)前系統(tǒng)時(shí)間+一個(gè)時(shí)間片來(lái)計(jì)算下一次時(shí)間，就是前面說(shuō)的schedule和scheduleAtFixedRate的區(qū)別了，其實(shí)內(nèi)部是通過(guò)正負(fù)數(shù)來(lái)判定的，也許java是不想增加參數(shù)，而又想增加程序的可讀性，才這樣做，其實(shí)通過(guò)正負(fù)判定是有些詭異的，也就是你如果在schedule方法傳入負(fù)數(shù)達(dá)到的功能和scheduleAtFixedRate的功能是一樣的，相反在scheduleAtFixedRate方法中傳入負(fù)數(shù)功能和schedule方法是一樣的。

同時(shí)你可以看到period為0，就是只執(zhí)行一次，所以時(shí)間片正負(fù)0都用上了，呵呵，然后再看看mainLoop接下來(lái)的部分：

if (!taskFired)// Taskhasn't yet fired; wait queue.wait(executionTime- currentTime);

這里是如果任務(wù)執(zhí)行時(shí)間還未到，就等待一段時(shí)間，當(dāng)然這個(gè)等待很可能會(huì)被其他的線程操作add和cancel的時(shí)候被喚醒，因?yàn)閮?nèi)部有notify方法，所以這個(gè)時(shí)間并不是完全準(zhǔn)確，在這里大多數(shù)情況下是考慮Timer內(nèi)部的task信息是穩(wěn)定的，cancel方法喚醒的話是另一回事。

最后：

if (taskFired) // Task fired; run it, holding no locks task.run();

如果線程需要執(zhí)行，那么調(diào)用它的run方法，而并非啟動(dòng)一個(gè)新的線程或從線程池中獲取一個(gè)線程來(lái)執(zhí)行，所以TimerTask的run方法并不是多線程的run方法，雖然實(shí)現(xiàn)了Runnable，但是僅僅是為了表示它是可執(zhí)行的，并不代表它必須通過(guò)線程的方式來(lái)執(zhí)行的。

總結(jié)

Timer和TimerTask的簡(jiǎn)單組合是多線程的嘛？

不是，一個(gè)Timer內(nèi)部包裝了“一個(gè)Thread”和“一個(gè)Task”隊(duì)列，這個(gè)隊(duì)列按照一定的方式將任務(wù)排隊(duì)處理，包含的線程在Timer的構(gòu)造方法調(diào)用時(shí)被啟動(dòng)，這個(gè)Thread的run方法無(wú)限循環(huán)這個(gè)Task隊(duì)列，若隊(duì)列為空且沒(méi)發(fā)生cancel操作，此時(shí)會(huì)一直等待，如果等待完成后，隊(duì)列還是為空，則認(rèn)為發(fā)生了cancel從而跳出死循環(huán)，結(jié)束任務(wù)；

循環(huán)中如果發(fā)現(xiàn)任務(wù)需要執(zhí)行的時(shí)間小于系統(tǒng)時(shí)間，則需要執(zhí)行，那么根據(jù)任務(wù)的時(shí)間片從新計(jì)算下次執(zhí)行時(shí)間，若時(shí)間片為0代表只執(zhí)行一次，則直接移除隊(duì)列即可。

但是是否能實(shí)現(xiàn)多線程呢？

可以，任何東西是否是多線程完全看個(gè)人意愿，多個(gè)Timer自然就是多線程的，每個(gè)Timer都有自己的線程處理邏輯，當(dāng)然Timer從這里來(lái)看并不是很適合很多任務(wù)在短時(shí)間內(nèi)的快速調(diào)度，至少不是很適合同一個(gè)timer上掛很多任務(wù)，在多線程的領(lǐng)域中我們更多是使用多線程中的：

Executors.newScheduledThreadPool

來(lái)完成對(duì)調(diào)度隊(duì)列中的線程池的處理，內(nèi)部通過(guò)new ScheduledThreadPoolExecutor來(lái)創(chuàng)建線程池的Executor的創(chuàng)建，當(dāng)然也可以調(diào)用：

Executors.unconfigurableScheduledExecutorService

方法來(lái)創(chuàng)建一個(gè)DelegatedScheduledExecutorService其實(shí)這個(gè)類(lèi)就是包裝了下下scheduleExecutor，也就是這只是一個(gè)殼，英文理解就是被委派的意思，被托管的意思。

到此這篇關(guān)于Java中的Timer與TimerTask原理詳解的文章就介紹到這了,更多相關(guān)Timer與TimerTask原理內(nèi)容請(qǐng)搜索腳本之家以前的文章或繼續(xù)瀏覽下面的相關(guān)文章希望大家以后多多支持腳本之家！

最新評(píng)論