引言

在日常的開(kāi)發(fā)工作當(dāng)中，線程池往往承載著一個(gè)應(yīng)用中最重要的業(yè)務(wù)邏輯面哼，因此我們有必要更多地去關(guān)注線程池的執(zhí)行情況橡疼，包括異常的處理和分析等等素邪。本文主要聚焦在如何正確使用線程池上红淡，以及提供一些實(shí)用的建議不狮。文中會(huì)稍微涉及到一些線程池實(shí)現(xiàn)原理方面的知識(shí)，但是不會(huì)做過(guò)多展開(kāi)在旱。網(wǎng)絡(luò)上關(guān)于線程池的原理以及源碼解析的文章有很多摇零，感興趣的同學(xué)可以自行查閱。

線程池的異常處理

UncaughtExceptionHandler

我們都知道Runnable接口中的run方法是不允許拋出異常的桶蝎，因此派生出這個(gè)線程的主線程可能無(wú)法直接獲得該線程在執(zhí)行過(guò)程中的異常信息驻仅。如下例：

public static void main(String[] args) throws Exception {? ? Thread thread = new Thread(() -> {? ? ? ? Uninterruptibles.sleepUninterruptibly(2, TimeUnit.SECONDS);? ? ? ? System.out.println(1 / 0); // 這行會(huì)導(dǎo)致報(bào)錯(cuò)！? ? });? ? thread.setUncaughtExceptionHandler((t, e) -> {? ? ? ? e.printStackTrace(); //如果你把這一行注釋掉登渣，這個(gè)程序?qū)⒉粫?huì)拋出任何異常.? ? });? ? thread.start();}

為什么會(huì)這樣呢噪服？其實(shí)我們看一下Thread中的源碼就會(huì)發(fā)現(xiàn)，Thread在執(zhí)行過(guò)程中如果遇到了異常绍豁，會(huì)先判斷當(dāng)前線程是否有設(shè)置UncaughtExceptionHandler芯咧，如果沒(méi)有，則會(huì)從線程所在的ThreadGroup中獲取竹揍。（**注意：**每個(gè)線程都有自己的ThreadGroup敬飒，即使你沒(méi)有指定，并且它實(shí)現(xiàn)了UncaughtExceptionHandler接口）我們看下ThreadGroup中默認(rèn)的對(duì)UncaughtExceptionHandler接口的實(shí)現(xiàn)：

public void uncaughtException(Thread t, Throwable e) {? ? if (parent != null) {? ? ? ? parent.uncaughtException(t, e);? ? } else {? ? ? ? Thread.UncaughtExceptionHandler ueh =? ? ? ? ? ? Thread.getDefaultUncaughtExceptionHandler();? ? ? ? if (ueh != null) {? ? ? ? ? ? ueh.uncaughtException(t, e);? ? ? ? } else if (!(e instanceof ThreadDeath)) {? ? ? ? ? ? System.err.print("Exception in thread \""? ? ? ? ? ? ? ? ? ? ? ? ? ? + t.getName() + "\" ");? ? ? ? ? ? e.printStackTrace(System.err);? ? ? ? }? ? }}

這個(gè)ThreadGroup如果有父ThreadGroup芬位，則調(diào)用父ThreadGroup的uncaughtException无拗，否則調(diào)用全局默認(rèn)的Thread.DefaultUncaughtExceptionHandler，如果全局的handler也沒(méi)有設(shè)置昧碉，則只是簡(jiǎn)單地將異常信息定位到System.err中英染，這就是為什么我們應(yīng)當(dāng)在創(chuàng)建線程的時(shí)候，去實(shí)現(xiàn)它的UncaughtExceptionHandler接口的原因被饿，這么做可以讓你更方便地去排查問(wèn)題四康。

通過(guò)execute提交任務(wù)給線程池

回到線程池這個(gè)話題，如果我們向線程池提交的任務(wù)中狭握，沒(méi)有對(duì)異常進(jìn)行try...catch處理闪金，并且運(yùn)行的時(shí)候出現(xiàn)了異常，那會(huì)對(duì)線程池造成什么影響呢论颅？答案是沒(méi)有影響哎垦，線程池依舊可以正常工作，但是異常卻被吞掉了恃疯。這通常來(lái)說(shuō)不是一個(gè)好事情漏设，因?yàn)槲覀冃枰玫皆嫉漠惓?duì)象去分析問(wèn)題。

那么怎樣才能拿到原始的異常對(duì)象呢今妄？我們從線程池的源碼著手開(kāi)始研究這個(gè)問(wèn)題郑口。當(dāng)然網(wǎng)上關(guān)于線程池的源碼解析文章有很多鸳碧，這里限于篇幅，直接給出最相關(guān)的部分代碼：

final void runWorker(Worker w) {? ? Thread wt = Thread.currentThread();? ? Runnable task = w.firstTask;? ? w.firstTask = null;? ? w.unlock(); // allow interrupts? ? boolean completedAbruptly = true;? ? try {? ? ? ? while (task != null || (task = getTask()) != null) {? ? ? ? ? ? w.lock();? ? ? ? ? ? // If pool is stopping, ensure thread is interrupted;? ? ? ? ? ? // if not, ensure thread is not interrupted.? This? ? ? ? ? ? // requires a recheck in second case to deal with? ? ? ? ? ? // shutdownNow race while clearing interrupt? ? ? ? ? ? if ((runStateAtLeast(ctl.get(), STOP) ||? ? ? ? ? ? ? ? (Thread.interrupted() &&? ? ? ? ? ? ? ? ? runStateAtLeast(ctl.get(), STOP))) &&? ? ? ? ? ? ? ? !wt.isInterrupted())? ? ? ? ? ? ? ? wt.interrupt();? ? ? ? ? ? try {? ? ? ? ? ? ? ? beforeExecute(wt, task);? ? ? ? ? ? ? ? Throwable thrown = null;? ? ? ? ? ? ? ? try {? ? ? ? ? ? ? ? ? ? task.run();? ? ? ? ? ? ? ? } catch (RuntimeException x) {? ? ? ? ? ? ? ? ? ? thrown = x; throw x;? ? ? ? ? ? ? ? } catch (Error x) {? ? ? ? ? ? ? ? ? ? thrown = x; throw x;? ? ? ? ? ? ? ? } catch (Throwable x) {? ? ? ? ? ? ? ? ? ? thrown = x; throw new Error(x);? ? ? ? ? ? ? ? } finally {? ? ? ? ? ? ? ? ? ? afterExecute(task, thrown);? ? ? ? ? ? ? ? }? ? ? ? ? ? } finally {? ? ? ? ? ? ? ? task = null;? ? ? ? ? ? ? ? w.completedTasks++;? ? ? ? ? ? ? ? w.unlock();? ? ? ? ? ? }? ? ? ? }? ? ? ? completedAbruptly = false;? ? } finally {? ? ? ? processWorkerExit(w, completedAbruptly);? ? }}

這個(gè)方法就是真正去執(zhí)行提交給線程池的任務(wù)的代碼潘酗。這里我們略去其中不相關(guān)的邏輯杆兵，重點(diǎn)關(guān)注第19行到第32行的邏輯，其中第23行是真正開(kāi)始執(zhí)行提交給線程池的任務(wù)仔夺，那么第20行是干什么的呢琐脏？其實(shí)就是在執(zhí)行提交給線程池的任務(wù)之前可以做一些前置工作，同樣的缸兔，我們看到第31行日裙，這個(gè)是在執(zhí)行完提交的任務(wù)之后，可以做一些后置工作惰蜜。beforeExecute這個(gè)我們暫且不管昂拂，重點(diǎn)關(guān)注下afterExecute這個(gè)方法。我們可以看到抛猖，在執(zhí)行任務(wù)過(guò)程中格侯，一旦拋出任何類(lèi)型的異常，都會(huì)提交給afterExecute這個(gè)方法财著，然而查看線程池的源代碼我們可以發(fā)現(xiàn)联四，默認(rèn)的afterExecute是個(gè)空實(shí)現(xiàn)，因此撑教，我們有必要繼承ThreadPoolExecutor去實(shí)現(xiàn)這個(gè)afterExecute方法朝墩。（看源碼我們可以發(fā)現(xiàn)這個(gè)afterExecute方法是protected類(lèi)型的，從官方注釋上也可以看到伟姐，這個(gè)方法就是推薦子類(lèi)去實(shí)現(xiàn)的）當(dāng)然收苏，這個(gè)方法不能隨意去實(shí)現(xiàn)，需要遵循一定的步驟愤兵，具體的官方注釋也有講鹿霸，這里摘抄如下：

* <pre> {@code

* class ExtendedExecutor extends ThreadPoolExecutor {

*? // ...

*? protected void afterExecute(Runnable r, Throwable t) {

*? ? super.afterExecute(r, t);

*? ? if (t == null && r instanceof Future<?>) {

*? ? ? try {

*? ? ? ? Object result = ((Future<?>) r).get();

*? ? ? } catch (CancellationException ce) {

*? ? ? ? ? t = ce;

*? ? ? } catch (ExecutionException ee) {

*? ? ? ? ? t = ee.getCause();

*? ? ? } catch (InterruptedException ie) {

*? ? ? ? ? Thread.currentThread().interrupt(); // ignore/reset

*? ? ? }

*? ? }

*? ? if (t != null)

*? ? ? System.out.println(t);

*? }

* }}</pre>

那么通過(guò)這種方式，就可以將原先可能被線程池吞掉的異常成功捕獲到秆乳，從而便于排查問(wèn)題懦鼠。

但是這里還有個(gè)小問(wèn)題，我們注意到在runWorker方法中矫夷，執(zhí)行task.run();語(yǔ)句之后，各種類(lèi)型的異常都被拋出了憋槐，那這些被拋出的異常去了哪里双藕？事實(shí)上這里的異常對(duì)象最終會(huì)被傳入到Thread的dispatchUncaughtException方法中，源碼如下：

private void dispatchUncaughtException(Throwable e) {? ? getUncaughtExceptionHandler().uncaughtException(this, e);}

可以看到它會(huì)去獲取UncaughtExceptionHandler的實(shí)現(xiàn)類(lèi)阳仔，然后調(diào)用其中的uncaughtException方法忧陪，這也就回到了我們上一小節(jié)所分析的UncaughtExceptionHandler實(shí)現(xiàn)的具體邏輯扣泊。那么為了拿到最原始的異常對(duì)象，除了實(shí)現(xiàn)UncaughtExceptionHandler接口之外嘶摊，也可以考慮實(shí)現(xiàn)afterExecute方法延蟹。

通過(guò)submit提交任務(wù)到線程池

這個(gè)同樣很簡(jiǎn)單，我們還是先回到submit方法的源碼：

public Future submit(Callable task) {? ? if (task == null) throw new NullPointerException();? ? RunnableFuture ftask = newTaskFor(task);? ? execute(ftask);? ? return ftask;}

這里的execute方法調(diào)用的是ThreadPoolExecutor中的execute方法叶堆，執(zhí)行邏輯跟通過(guò)execute提交任務(wù)到線程池是一樣的阱飘。我們先重點(diǎn)關(guān)注這里的newTaskFor方法，其源碼如下：

protected RunnableFuture newTaskFor(Callable callable) {? ? return new FutureTask(callable);}復(fù)制代碼

可以看到提交的Callable對(duì)象用FutureTask封裝起來(lái)了虱颗。那么我們知道最終會(huì)執(zhí)行到上述runWorker這個(gè)方法中沥匈，并且最核心的執(zhí)行邏輯就是task.run();這行代碼。我們知道這里的task其實(shí)是FutureTask類(lèi)型忘渔，因此我們有必要看一下FutureTask中的run方法的實(shí)現(xiàn)：

public void run() {? ? if (state != NEW ||? ? ? ? !UNSAFE.compareAndSwapObject(this, runnerOffset,? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? null, Thread.currentThread()))? ? ? ? return;? ? try {? ? ? ? Callable c = callable;? ? ? ? if (c != null && state == NEW) {? ? ? ? ? ? V result;? ? ? ? ? ? boolean ran;? ? ? ? ? ? try {? ? ? ? ? ? ? ? result = c.call();? ? ? ? ? ? ? ? ran = true;? ? ? ? ? ? } catch (Throwable ex) {? ? ? ? ? ? ? ? result = null;? ? ? ? ? ? ? ? ran = false;? ? ? ? ? ? ? ? setException(ex);? ? ? ? ? ? }? ? ? ? ? ? if (ran)? ? ? ? ? ? ? ? set(result);? ? ? ? }? ? } finally {? ? ? ? // runner must be non-null until state is settled to? ? ? ? // prevent concurrent calls to run()? ? ? ? runner = null;? ? ? ? // state must be re-read after nulling runner to prevent? ? ? ? // leaked interrupts? ? ? ? int s = state;? ? ? ? if (s >= INTERRUPTING)? ? ? ? ? ? handlePossibleCancellationInterrupt(s);? ? }}

可以看到這其中跟異常相關(guān)的最關(guān)鍵的代碼就在第17行高帖，也就是setException(ex);這個(gè)地方。我們看一下這個(gè)地方的實(shí)現(xiàn)：

protected void setException(Throwable t) {? ? if (UNSAFE.compareAndSwapInt(this, stateOffset, NEW, COMPLETING)) {? ? ? ? outcome = t;? ? ? ? UNSAFE.putOrderedInt(this, stateOffset, EXCEPTIONAL); // final state? ? ? ? finishCompletion();? ? }}

這里最關(guān)鍵的地方就是將異常對(duì)象賦值給了outcome畦粮，outcome是FutureTask中的成員變量散址，我們通過(guò)調(diào)用submit方法，拿到一個(gè)Future對(duì)象之后宣赔，再調(diào)用它的get方法预麸，其中最核心的方法就是report方法，下面給出每個(gè)方法的源碼：

首先是get方法：

public V get() throws InterruptedException, ExecutionException {? ? int s = state;? ? if (s <= COMPLETING)? ? ? ? s = awaitDone(false, 0L);? ? return report(s);}

可以看到最終調(diào)用了report方法拉背，其源碼如下：

private V report(int s) throws ExecutionException {? ? Object x = outcome;? ? if (s == NORMAL)? ? ? ? return (V)x;? ? if (s >= CANCELLED)? ? ? ? throw new CancellationException();? ? throw new ExecutionException((Throwable)x);}

上面是一些狀態(tài)判斷师崎，如果當(dāng)前任務(wù)不是正常執(zhí)行完畢，或者被取消的話椅棺，那么這里的x其實(shí)就是原始的異常對(duì)象犁罩，可以看到會(huì)被ExecutionException包裝。因此在你調(diào)用get方法時(shí)两疚，可能會(huì)拋出ExecutionException異常床估，那么調(diào)用它的getCause方法就可以拿到最原始的異常對(duì)象了。

綜上所述诱渤，針對(duì)提交給線程池的任務(wù)可能會(huì)拋出異常這一問(wèn)題丐巫，主要有以下兩種處理思路：

在提交的任務(wù)當(dāng)中自行try...catch，但這里有個(gè)不好的地方就是如果你會(huì)提交多種類(lèi)型的任務(wù)到線程池中勺美，每種類(lèi)型的任務(wù)都需要自行將異常try...catch住递胧，比較繁瑣。而且如果你只是catch(Exception e)赡茸，可能依然會(huì)漏掉一些包括Error類(lèi)型的異常缎脾，那為了保險(xiǎn)起見(jiàn)，你可以考慮catch(Throwable t).

自行實(shí)現(xiàn)線程池的afterExecute方法占卧，或者實(shí)現(xiàn)Thread的UncaughtExceptionHandler接口遗菠。

下面給出我個(gè)人創(chuàng)建線程池的一個(gè)示例联喘，供大家參考：

BlockingQueue queue = new ArrayBlockingQueue<>(DEFAULT_QUEUE_SIZE);statisticsThreadPool = new ThreadPoolExecutor(DEFAULT_CORE_POOL_SIZE, DEFAULT_MAX_POOL_SIZE,? ? ? ? 60, TimeUnit.SECONDS, queue, new ThreadFactoryBuilder()? ? ? ? .setThreadFactory(new ThreadFactory() {? ? ? ? ? ? private int count = 0;? ? ? ? ? ? private String prefix = "StatisticsTask";? ? ? ? ? ? @Override? ? ? ? ? ? public Thread newThread(Runnable r) {? ? ? ? ? ? ? ? return new Thread(r, prefix + "-" + count++);? ? ? ? ? ? }? ? ? ? }).setUncaughtExceptionHandler((t, e) -> {? ? ? ? ? ? String threadName = t.getName();? ? ? ? ? ? logger.error("statisticsThreadPool error occurred! threadName: {}, error msg: {}", threadName, e.getMessage(), e);? ? ? ? }).build(), (r, executor) -> {? ? if (!executor.isShutdown()) {? ? ? ? logger.warn("statisticsThreadPool is too busy! waiting to insert task to queue! ");? ? ? ? Uninterruptibles.putUninterruptibly(executor.getQueue(), r);? ? }}) {? ? @Override? ? protected void afterExecute(Runnable r, Throwable t) {? ? ? ? super.afterExecute(r, t);? ? ? ? if (t == null && r instanceof Future) {? ? ? ? ? ? try {? ? ? ? ? ? ? ? Future future = (Future) r;? ? ? ? ? ? ? ? future.get();? ? ? ? ? ? } catch (CancellationException ce) {? ? ? ? ? ? ? ? t = ce;? ? ? ? ? ? } catch (ExecutionException ee) {? ? ? ? ? ? ? ? t = ee.getCause();? ? ? ? ? ? } catch (InterruptedException ie) {? ? ? ? ? ? ? ? Thread.currentThread().interrupt(); // ignore/reset? ? ? ? ? ? }? ? ? ? }? ? ? ? if (t != null) {? ? ? ? ? ? logger.error("statisticsThreadPool error msg: {}", t.getMessage(), t);? ? ? ? }? ? }};statisticsThreadPool.prestartAllCoreThreads();

線程數(shù)的設(shè)置

我們知道任務(wù)一般有兩種：CPU密集型和IO密集型。那么面對(duì)CPU密集型的任務(wù)辙纬，線程數(shù)不宜過(guò)多豁遭，一般選擇CPU核心數(shù)+1或者核心數(shù)的2倍是比較合理的一個(gè)值。因此我們可以考慮將corePoolSize設(shè)置為CPU核心數(shù)+1贺拣，maxPoolSize設(shè)置為核心數(shù)的2倍蓖谢。那么同樣的，面對(duì)IO密集型任務(wù)時(shí)纵柿，我們可以考慮以核心數(shù)乘以4倍作為核心線程數(shù)蜈抓，然后核心數(shù)乘以5倍作為最大線程數(shù)的方式去設(shè)置線程數(shù)，這樣的設(shè)置會(huì)比直接拍腦袋設(shè)置一個(gè)值會(huì)更合理一些昂儒。

當(dāng)然總的線程數(shù)不宜過(guò)多沟使，控制在100個(gè)線程以?xún)?nèi)比較合理，否則線程數(shù)過(guò)多可能會(huì)導(dǎo)致頻繁地上下文切換渊跋，導(dǎo)致系統(tǒng)性能反不如前腊嗡。

如何正確關(guān)閉一個(gè)線程池

說(shuō)到如何正確去關(guān)閉一個(gè)線程池，這里面也有點(diǎn)講究拾酝。為了實(shí)現(xiàn)優(yōu)雅停機(jī)的目標(biāo)燕少，我們應(yīng)當(dāng)先調(diào)用shutdown方法，調(diào)用這個(gè)方法也就意味著蒿囤，這個(gè)線程池不會(huì)再接收任何新的任務(wù)客们，但是已經(jīng)提交的任務(wù)還會(huì)繼續(xù)執(zhí)行，包括隊(duì)列中的材诽。所以底挫，之后你還應(yīng)當(dāng)調(diào)用awaitTermination方法，這個(gè)方法可以設(shè)定線程池在關(guān)閉之前的最大超時(shí)時(shí)間脸侥，如果在超時(shí)時(shí)間結(jié)束之前線程池能夠正常關(guān)閉建邓，這個(gè)方法會(huì)返回true，否則睁枕，一旦超時(shí)官边，就會(huì)返回false。通常來(lái)說(shuō)我們不可能無(wú)限制地等待下去外遇，因此需要我們事先預(yù)估一個(gè)合理的超時(shí)時(shí)間注簿，然后去使用這個(gè)方法。

如果awaitTermination方法返回false跳仿，你又希望盡可能在線程池關(guān)閉之后再做其他資源回收工作诡渴，你可以考慮再調(diào)用一下shutdownNow方法，此時(shí)隊(duì)列中所有尚未被處理的任務(wù)都會(huì)被丟棄塔嬉，同時(shí)會(huì)設(shè)置線程池中每個(gè)線程的中斷標(biāo)志位玩徊。shutdownNow并不保證一定可以讓正在運(yùn)行的線程停止工作，除非提交給線程的任務(wù)能夠正確響應(yīng)中斷谨究。到了這一步恩袱，你可以考慮繼續(xù)調(diào)用awaitTermination方法，或者你直接放棄胶哲，去做接下來(lái)要做的事情畔塔。

線程池中的其他有用方法

大家可能有留意到，我在創(chuàng)建線程池的時(shí)候鸯屿，還調(diào)用了這個(gè)方法：prestartAllCoreThreads澈吨。這個(gè)方法有什么作用呢？我們知道一個(gè)線程池創(chuàng)建出來(lái)之后寄摆，在沒(méi)有給它提交任何任務(wù)之前谅辣，這個(gè)線程池中的線程數(shù)為0。有時(shí)候我們事先知道會(huì)有很多任務(wù)會(huì)提交給這個(gè)線程池婶恼，但是等它一個(gè)個(gè)去創(chuàng)建新線程開(kāi)銷(xiāo)太大桑阶，影響系統(tǒng)性能，因此可以考慮在創(chuàng)建線程池的時(shí)候就將所有的核心線程全部一次性創(chuàng)建完畢勾邦，這樣系統(tǒng)起來(lái)之后就可以直接使用了蚣录。

其實(shí)線程池中還提供了其他一些比較有意思的方法。比如我們現(xiàn)在設(shè)想一個(gè)場(chǎng)景眷篇，當(dāng)一個(gè)線程池負(fù)載很高萎河，快要撐爆導(dǎo)致觸發(fā)拒絕策略時(shí)，有沒(méi)有什么辦法可以緩解這一問(wèn)題蕉饼？其實(shí)是有的虐杯，因?yàn)榫€程池提供了設(shè)置核心線程數(shù)和最大線程數(shù)的方法，它們分別是setCorePoolSize方法和setMaximumPoolSize方法椎椰。是的厦幅，**線程池創(chuàng)建完畢之后也是可以更改其線程數(shù)的！**因此慨飘，面對(duì)線程池高負(fù)荷運(yùn)行的情況确憨，我們可以這么處理：

起一個(gè)定時(shí)輪詢(xún)線程（守護(hù)類(lèi)型），定時(shí)檢測(cè)線程池中的線程數(shù)瓤的，具體來(lái)說(shuō)就是調(diào)用getActiveCount方法

當(dāng)發(fā)現(xiàn)線程數(shù)超過(guò)了核心線程數(shù)大小時(shí)休弃，可以考慮將CorePoolSize和MaximumPoolSize的數(shù)值同時(shí)乘以2，當(dāng)然這里不建議設(shè)置很大的線程數(shù)圈膏，因?yàn)椴⒉皇蔷€程越多越好的塔猾，可以考慮設(shè)置一個(gè)上限值，比如50, 100之類(lèi)的稽坤。

同時(shí)丈甸，去獲取隊(duì)列中的任務(wù)數(shù)糯俗，具體來(lái)說(shuō)是調(diào)用getQueue方法再調(diào)用size方法。當(dāng)隊(duì)列中的任務(wù)數(shù)少于隊(duì)列大小的二分之一時(shí)睦擂，我們可以認(rèn)為現(xiàn)在線程池的負(fù)載沒(méi)有那么高了得湘，因此可以考慮在線程池先前有擴(kuò)容過(guò)的情況下，將CorePoolSize和MaximumPoolSize還原回去顿仇，也就是除以2

具體來(lái)說(shuō)如下圖：

以上是我個(gè)人建議的一種使用線程池的方式淘正。

線程池一定是最佳方案嗎？

線程池并非在任何情況下都是性能最優(yōu)的方案臼闻。如果是一個(gè)追求極致性能的場(chǎng)景鸿吆，可以考慮使用Disruptor，這是一個(gè)高性能隊(duì)列述呐。排除Disruptor不談惩淳，單純基于JDK的話會(huì)不會(huì)有更好地方案？答案是有的乓搬。

我們知道在一個(gè)線程池中黎泣，多個(gè)線程是共用一個(gè)隊(duì)列的，因此在任務(wù)很多的情況下缤谎，需要對(duì)這個(gè)隊(duì)列進(jìn)行頻繁讀寫(xiě)抒倚，為了防止沖突因此需要加鎖。事實(shí)上在閱讀線程池源代碼的時(shí)候就可以發(fā)現(xiàn)坷澡，里面充斥著各種加鎖的代碼托呕，那有沒(méi)有更好的實(shí)現(xiàn)方式呢？其實(shí)我們可以考慮創(chuàng)建一個(gè)由單線程線程池構(gòu)成的列表频敛，每個(gè)線程池都使用有界隊(duì)列這種方式去實(shí)現(xiàn)多線程项郊。這么做的好處是，每個(gè)線程池中的隊(duì)列都只會(huì)被一個(gè)線程去操作斟赚，這樣就沒(méi)有競(jìng)爭(zhēng)的問(wèn)題着降。

其實(shí)這種用空間換時(shí)間的思路借鑒了Netty中的EventLoop的實(shí)現(xiàn)機(jī)制。試想拗军，如果線程池的性能真的有那么好任洞，為什么Netty不用呢？

其他需要注意的地方

任何情況下都不應(yīng)該使用可伸縮線程池（線程的創(chuàng)建和銷(xiāo)毀開(kāi)銷(xiāo)是很大的）

任何情況下都不應(yīng)該使用無(wú)界隊(duì)列发侵，單測(cè)除外（有界隊(duì)列常用的有ArrayBlockingQueue和LinkedBlockingQueue交掏，前者基于數(shù)組實(shí)現(xiàn)，后者基于鏈表刃鳄。從性能表現(xiàn)上來(lái)看盅弛，LinkedBlockingQueue的吞吐量更高但是性能并不穩(wěn)定，實(shí)際情況下應(yīng)當(dāng)使用哪一種建議自行測(cè)試之后決定。順便說(shuō)一句挪鹏，Executors的newFixedThreadPool采用的是LinkedBlockingQueue）

推薦自行實(shí)現(xiàn)RejectedExecutionHandler见秽，JDK自帶的都不是很好用，你可以在里面實(shí)現(xiàn)自己的邏輯讨盒。如果需要一些特定的上下文信息张吉，你可以在Runnable實(shí)現(xiàn)類(lèi)中添加一些自己的東西，這樣在RejectedExecutionHandler中就可以直接使用了催植。

怎樣做到不丟任務(wù)

這里其實(shí)指的是一種特殊情況，就是比如突然遇到了一股流量尖峰勺择，導(dǎo)致線程池負(fù)載已經(jīng)非常高了创南，即快要觸發(fā)拒絕策略的時(shí)候，我們可以怎么做來(lái)盡量防止提交的任務(wù)不會(huì)丟失省核。一般來(lái)說(shuō)當(dāng)遇到這種情況的時(shí)候稿辙，應(yīng)當(dāng)盡快觸發(fā)報(bào)警通知研發(fā)人員來(lái)處理。之后不管是限流也好气忠，還是增加機(jī)器也好邻储，甚至是上kafka，redis甚至是數(shù)據(jù)庫(kù)用來(lái)暫存任務(wù)數(shù)據(jù)也是可以的旧噪，但畢竟遠(yuǎn)水救不了近火吨娜，如果我們希望在正式解決這個(gè)問(wèn)題之前，先盡可能地緩解淘钟，可以考慮怎么做呢宦赠？

首先可以考慮的就是我前面有提過(guò)的動(dòng)態(tài)增大線程池中的線程數(shù)，但是假如說(shuō)已經(jīng)擴(kuò)容過(guò)了米母，此時(shí)不應(yīng)繼續(xù)擴(kuò)容勾扭，否則可能導(dǎo)致系統(tǒng)的吞吐量更低。在這種情況下铁瞒，應(yīng)當(dāng)自行實(shí)現(xiàn)RejectedExecutionHandler妙色，具體來(lái)說(shuō)就是在實(shí)現(xiàn)類(lèi)中，單獨(dú)開(kāi)一個(gè)單線程的線程池慧耍，然后調(diào)用原線程池的getQueue方法的put方法身辨，將塞不進(jìn)去的任務(wù)再次嘗試塞進(jìn)去。當(dāng)然在隊(duì)列滿(mǎn)的時(shí)候是塞不進(jìn)去的芍碧，但那至少也只是阻塞了這個(gè)單獨(dú)的線程而已栅表，并不影響主流程。

當(dāng)然师枣，這種方案是治標(biāo)不治本的怪瓶，面對(duì)流量激增這種場(chǎng)景其實(shí)業(yè)界有很多成熟的做法，只是單純從線程池的角度來(lái)看的話，這種方式不失為一種臨時(shí)的解決方案洗贰。

本文到這里就結(jié)束了找岖，喜歡的朋友可以幫忙轉(zhuǎn)發(fā)和關(guān)注一下，感謝支持敛滋！

為了感謝支持我的朋友许布！整理了一份Java高級(jí)架構(gòu)資料、Spring源碼分析绎晃、Dubbo蜜唾、Redis、Netty庶艾、zookeeper袁余、Spring cloud、分布式等資料

關(guān)注公眾號(hào)【Java耕耘者】咱揍，專(zhuān)注于Spring源碼分析颖榜、Dubbo、Redis煤裙、Netty掩完、zookeeper、Spring cloud硼砰、分布式等全棧技術(shù)且蓬，定期視頻教程分享，關(guān)注后回復(fù) Java 题翰，領(lǐng)取我為你精心準(zhǔn)備的 Java 干貨缅疟！

本號(hào)專(zhuān)注Java源碼分析。喜歡底層源碼的朋友可以來(lái)交流探討遍愿。交流群：818491202 驗(yàn)證：33

作者：呂亞?wèn)|鏈接：https://juejin.im/post/5d4e5c9 de51d453c11684c25