在日常的開(kāi)發(fā)工作當(dāng)中，線(xiàn)程池往往承載著一個(gè)應(yīng)用中最重要的業(yè)務(wù)邏輯，因此我們有必要更多地去關(guān)注線(xiàn)程池的執(zhí)行情況，包括異常的處理和分析等。本文主要聚焦在如何正確使用線(xiàn)程池上，以及提供一些實(shí)用的建議。文中會(huì)稍微涉及到一些線(xiàn)程池實(shí)現(xiàn)原理方面的知識(shí)，但是不會(huì)過(guò)多展開(kāi)。
線(xiàn)程池的異常處理
UncaughtExceptionHandler
我們都知道Runnable接口中的run方法是不允許拋出異常的，因此派生出這個(gè)線(xiàn)程的主線(xiàn)程可能無(wú)法直接獲得該線(xiàn)程在執(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)前線(xiàn)程是否有設(shè)置UncaughtExceptionHandler，如果沒(méi)有，則會(huì)從線(xiàn)程所在的ThreadGroup中獲取。
注意：每個(gè)線(xiàn)程都有自己的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)建線(xiàn)程的時(shí)候，去實(shí)現(xiàn)它的UncaughtExceptionHandler接口的原因，這么做可以讓你更方便地去排查問(wèn)題。
通過(guò)execute提交任務(wù)給線(xiàn)程池
回到線(xiàn)程池這個(gè)話(huà)題，如果我們向線(xiàn)程池提交的任務(wù)中，沒(méi)有對(duì)異常進(jìn)行try...catch處理，并且運(yùn)行的時(shí)候出現(xiàn)了異常，那會(huì)對(duì)線(xiàn)程池造成什么影響呢？答案是沒(méi)有影響，線(xiàn)程池依舊可以正常工作，但是異常卻被吞掉了。這通常來(lái)說(shuō)不是一個(gè)好事情，因?yàn)槲覀冃枰玫皆嫉漠惓?duì)象去分析問(wèn)題。
那么怎樣才能拿到原始的異常對(duì)象呢？我們從線(xiàn)程池的源碼著手開(kāi)始研究這個(gè)問(wèn)題。當(dāng)然網(wǎng)上關(guān)于線(xià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();
}//歡迎加入Java開(kāi)發(fā)交流君樣：909038429
}
completedAbruptly = false;
} finally {
processWorkerExit(w, completedAbruptly);
}
}
這個(gè)方法就是真正去執(zhí)行提交給線(xiàn)程池的任務(wù)的代碼。
這里我們略去其中不相關(guān)的邏輯，重點(diǎn)關(guān)注第19行到第32行的邏輯，其中第23行是真正開(kāi)始執(zhí)行提交給線(xiàn)程池的任務(wù)，那么第20行是干什么的呢？其實(shí)就是在執(zhí)行提交給線(xiàn)程池的任務(wù)之前可以做一些前置工作，同樣的，我們看到第31行，這個(gè)是在執(zhí)行完提交的任務(wù)之后，可以做一些后置工作。
beforeExecute這個(gè)我們暫且不管，重點(diǎn)關(guān)注下afterExecute這個(gè)方法。我們可以看到，在執(zhí)行任務(wù)過(guò)程中，一旦拋出任何類(lèi)型的異常，都會(huì)提交給afterExecute這個(gè)方法，然而查看線(xiàn)程池的源代碼我們可以發(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ò)這種方式，就可以將原先可能被線(xiàn)程池吞掉的異常成功捕獲到，從而便于排查問(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ù)到線(xiàn)程池
這個(gè)同樣很簡(jiǎn)單，我們還是先回到submit方法的源碼：
public <T> Future<T> submit(Callable<T> task) {
if (task == null) throw new NullPointerException();
RunnableFuture<T> ftask = newTaskFor(task);
execute(ftask);
return ftask;
}
這里的execute方法調(diào)用的是ThreadPoolExecutor中的execute方法，執(zhí)行邏輯跟通過(guò)execute提交任務(wù)到線(xiàn)程池是一樣的。我們先重點(diǎn)關(guān)注這里的newTaskFor方法，其源碼如下：
protected <T> RunnableFuture<T> newTaskFor(Callable<T> callable) {
return new FutureTask<T>(callable);
}
可以看到提交的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<V> 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();
}//歡迎加入Java開(kāi)發(fā)交流君樣：909038429
}
這里最關(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í)行完畢，或者被取消的話(huà)，那么這里的x其實(shí)就是原始的異常對(duì)象，可以看到會(huì)被ExecutionException包裝。因此在你調(diào)用get方法時(shí)，可能會(huì)拋出ExecutionException異常，那么調(diào)用它的getCause方法就可以拿到最原始的異常對(duì)象了。
綜上所述，針對(duì)提交給線(xiàn)程池的任務(wù)可能會(huì)拋出異常這一問(wèn)題，主要有以下兩種處理思路：
1.在提交的任務(wù)當(dāng)中自行try...catch，但這里有個(gè)不好的地方就是如果你會(huì)提交多種類(lèi)型的任務(wù)到線(xiàn)程池中，每種類(lèi)型的任務(wù)都需要自行將異常try...catch住，比較繁瑣。而且如果你只是catch(Exception e)，可能依然會(huì)漏掉一些包括Error類(lèi)型的異常，那為了保險(xiǎn)起見(jiàn)，可以考慮catch(Throwable t)。
2.自行實(shí)現(xiàn)線(xiàn)程池的afterExecute方法，或者實(shí)現(xiàn)Thread的UncaughtExceptionHandler接口。
下面給出我個(gè)人創(chuàng)建線(xiàn)程池的一個(gè)示例，供大家參考：
BlockingQueue<Runnable> 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();
線(xiàn)程數(shù)的設(shè)置
我們知道任務(wù)一般有兩種：CPU密集型和IO密集型。那么面對(duì)CPU密集型的任務(wù)，線(xiàn)程數(shù)不宜過(guò)多，一般選擇CPU核心數(shù)+1或者核心數(shù)的2倍是比較合理的一個(gè)值。因此我們可以考慮將corePoolSize設(shè)置為CPU核心數(shù)+1，maxPoolSize設(shè)置為核心數(shù)的2倍。
同樣的，面對(duì)IO密集型任務(wù)時(shí)，我們可以考慮以核心數(shù)乘以4倍作為核心線(xiàn)程數(shù)，然后核心數(shù)乘以5倍作為最大線(xiàn)程數(shù)的方式去設(shè)置線(xiàn)程數(shù)，這樣的設(shè)置會(huì)比直接拍腦袋設(shè)置一個(gè)值會(huì)更合理一些。
當(dāng)然總的線(xiàn)程數(shù)不宜過(guò)多，控制在100個(gè)線(xiàn)程以?xún)?nèi)比較合理，否則線(xiàn)程數(shù)過(guò)多可能會(huì)導(dǎo)致頻繁地上下文切換，導(dǎo)致系統(tǒng)性能反不如前。
如何正確關(guān)閉一個(gè)線(xiàn)程池
說(shuō)到如何正確去關(guān)閉一個(gè)線(xiàn)程池，這里面也有點(diǎn)講究。為了實(shí)現(xiàn)優(yōu)雅停機(jī)的目標(biāo)，我們應(yīng)當(dāng)先調(diào)用shutdown方法，調(diào)用這個(gè)方法也就意味著，這個(gè)線(xiàn)程池不會(huì)再接收任何新的任務(wù)，但是已經(jīng)提交的任務(wù)還會(huì)繼續(xù)執(zhí)行，包括隊(duì)列中的。所以，之后你還應(yīng)當(dāng)調(diào)用awaitTermination方法，這個(gè)方法可以設(shè)定線(xiàn)程池在關(guān)閉之前的最大超時(shí)時(shí)間，如果在超時(shí)時(shí)間結(jié)束之前線(xiàn)程池能夠正常關(guān)閉，這個(gè)方法會(huì)返回true，否則，一旦超時(shí)，就會(huì)返回false。通常來(lái)說(shuō)我們不可能無(wú)限制地等待下去，因此需要我們事先預(yù)估一個(gè)合理的超時(shí)時(shí)間，然后去使用這個(gè)方法。
如果awaitTermination方法返回false，你又希望盡可能在線(xiàn)程池關(guān)閉之后再做其他資源回收工作，可以考慮再調(diào)用一下shutdownNow方法，此時(shí)隊(duì)列中所有尚未被處理的任務(wù)都會(huì)被丟棄，同時(shí)會(huì)設(shè)置線(xiàn)程池中每個(gè)線(xiàn)程的中斷標(biāo)志位。shutdownNow并不保證一定可以讓正在運(yùn)行的線(xiàn)程停止工作，除非提交給線(xiàn)程的任務(wù)能夠正確響應(yīng)中斷。到了這一步，可以考慮繼續(xù)調(diào)用awaitTermination方法，或者直接放棄，去做接下來(lái)要做的事情。
線(xiàn)程池中的其他有用方法
大家可能有留意到，我在創(chuàng)建線(xiàn)程池的時(shí)候，還調(diào)用了這個(gè)方法：prestartAllCoreThreads。這個(gè)方法有什么作用呢？我們知道一個(gè)線(xiàn)程池創(chuàng)建出來(lái)之后，在沒(méi)有給它提交任何任務(wù)之前，這個(gè)線(xiàn)程池中的線(xiàn)程數(shù)為0。有時(shí)候我們事先知道會(huì)有很多任務(wù)會(huì)提交給這個(gè)線(xiàn)程池，但是等它一個(gè)個(gè)去創(chuàng)建新線(xiàn)程開(kāi)銷(xiāo)太大，影響系統(tǒng)性能，因此可以考慮在創(chuàng)建線(xiàn)程池的時(shí)候就將所有的核心線(xiàn)程全部一次性創(chuàng)建完畢，這樣系統(tǒng)起來(lái)之后就可以直接使用了。
其實(shí)線(xiàn)程池中還提供了其他一些比較有意思的方法。比如我們現(xiàn)在設(shè)想一個(gè)場(chǎng)景，當(dāng)一個(gè)線(xiàn)程池負(fù)載很高，快要撐爆導(dǎo)致觸發(fā)拒絕策略時(shí)，有沒(méi)有什么辦法可以緩解這一問(wèn)題？其實(shí)是有的，因?yàn)榫€(xiàn)程池提供了設(shè)置核心線(xiàn)程數(shù)和最大線(xiàn)程數(shù)的方法，它們分別是setCorePoolSize方法和setMaximumPoolSize方法。是的，線(xiàn)程池創(chuàng)建完畢之后也是可以更改其線(xiàn)程數(shù)的！因此，面對(duì)線(xiàn)程池高負(fù)荷運(yùn)行的情況，我們可以這么處理：
起一個(gè)定時(shí)輪詢(xún)線(xiàn)程（守護(hù)類(lèi)型），定時(shí)檢測(cè)線(xiàn)程池中的線(xiàn)程數(shù)，具體來(lái)說(shuō)就是調(diào)用getActiveCount方法。
當(dāng)發(fā)現(xiàn)線(xiàn)程數(shù)超過(guò)了核心線(xiàn)程數(shù)大小時(shí)，可以考慮將CorePoolSize和MaximumPoolSize的數(shù)值同時(shí)乘以2，當(dāng)然這里不建議設(shè)置很大的線(xiàn)程數(shù)，因?yàn)椴⒉皇蔷€(xià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)在線(xiàn)程池的負(fù)載沒(méi)有那么高了，因此可以考慮在線(xiàn)程池先前有擴(kuò)容過(guò)的情況下，將CorePoolSize和MaximumPoolSize還原回去，也就是除以2。
具體來(lái)說(shuō)如下圖：
以上是我個(gè)人建議的一種使用線(xiàn)程池的方式。
線(xiàn)程池一定是最佳方案嗎？
線(xiàn)程池并非在任何情況下都是性能最優(yōu)的方案。如果是一個(gè)追求極致性能的場(chǎng)景，可以考慮使用Disruptor，這是一個(gè)高性能隊(duì)列。排除Disruptor不談，單純基于JDK的話(huà)會(huì)不會(huì)有更好的方案？答案是有的。
我們知道在一個(gè)線(xiàn)程池中，多個(gè)線(xiàn)程是共用一個(gè)隊(duì)列的，因此在任務(wù)很多的情況下，需要對(duì)這個(gè)隊(duì)列進(jìn)行頻繁讀寫(xiě)，為了防止沖突因此需要加鎖。事實(shí)上在閱讀線(xiàn)程池源代碼的時(shí)候就可以發(fā)現(xiàn)，里面充斥著各種加鎖的代碼，那有沒(méi)有更好的實(shí)現(xiàn)方式呢？
其實(shí)我們可以考慮創(chuàng)建一個(gè)由單線(xiàn)程線(xiàn)程池構(gòu)成的列表，每個(gè)線(xiàn)程池都使用有界隊(duì)列這種方式去實(shí)現(xiàn)多線(xiàn)程。這么做的好處是，每個(gè)線(xiàn)程池中的隊(duì)列都只會(huì)被一個(gè)線(xiàn)程去操作，這樣就沒(méi)有競(jìng)爭(zhēng)的問(wèn)題。
其實(shí)這種用空間換時(shí)間的思路借鑒了Netty中EventLoop的實(shí)現(xiàn)機(jī)制。試想，如果線(xiàn)程池的性能真的有那么好，為什么Netty不用呢？
其他需要注意的地方
1.任何情況下都不應(yīng)該使用可伸縮線(xiàn)程池（線(xiàn)程的創(chuàng)建和銷(xiāo)毀開(kāi)銷(xiāo)是很大的）。
2.任何情況下都不應(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。
3.推薦自行實(shí)現(xiàn)RejectedExecutionHandler，JDK自帶的都不是很好用，你可以在里面實(shí)現(xiàn)自己的邏輯。如果需要一些特定的上下文信息，可以在Runnable實(shí)現(xiàn)類(lèi)中添加一些自己的東西，這樣在RejectedExecutionHandler中就可以直接使用了。
怎樣做到不丟任務(wù)
這里其實(shí)指的是一種特殊情況，就是比如突然遇到了一股流量尖峰，導(dǎo)致線(xiàn)程池負(fù)載已經(jīng)非常高了，即快要觸發(fā)拒絕策略的時(shí)候，我們可以怎么做來(lái)盡量防止提交的任務(wù)丟失。一般來(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)題之前，先盡可能地緩解，可以考慮怎么做呢？
首先可以考慮的就是我前面提到的動(dòng)態(tài)增大線(xiàn)程池中的線(xiàn)程數(shù)，但是假如已經(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è)單線(xiàn)程的線(xiàn)程池，然后調(diào)用原線(xiàn)程池的getQueue方法的put方法，將塞不進(jìn)去的任務(wù)再次嘗試塞進(jìn)去。當(dāng)然在隊(duì)列滿(mǎn)的時(shí)候是塞不進(jìn)去的，但那至少也只是阻塞了這個(gè)單獨(dú)的線(xiàn)程而已，并不影響主流程。
當(dāng)然，這種方案是治標(biāo)不治本的，面對(duì)流量激增這種場(chǎng)景其實(shí)業(yè)界有很多成熟的做法，只是單純從線(xiàn)程池的角度來(lái)看的話(huà)，這種方式不失為一種臨時(shí)有效的解決方案。
最新2020整理收集的一些高頻面試題（都整理成文檔），有很多干貨，包含mysql，netty，spring，線(xiàn)程，spring cloud、jvm、源碼、算法等詳細(xì)講解，也有詳細(xì)的學(xué)習(xí)規(guī)劃圖，面試題整理等，需要獲取這些內(nèi)容的朋友請(qǐng)加Q君樣：909038429
/./*歡迎加入java交流Q君樣：909038429一起吹水聊天
