背景
有一個功能，這個功能里需要調用幾個不同的RPC請求，一開始不以為然，沒覺得什么，所以所有的RPC請求都是 串行 執行，后來發現部分RPC返回時間比較長導致此功能接口時間耗時較長，于是乎就使用了JDK8新特性CompletableFuture打算將這些不同的RPC請求異步執行，等所有的RPC請求結束后，再返回請求結果。
因為功能比較簡單沒什么特殊的，所以這里在使用CompletableFuture的時候，并沒有自定義線程池，默認那么就是ForkJoinPool。下面看下偽代碼：
CompletableFuture task1 = CompletableFuture.runAsync(()->{
/**
* 這里會調用一個RPC請求，而這個RPC請求處理的過程中會通過SPL機制load指定接口的實現，這個接口所在jar存在于WEB-INFO/lib
*/
System.out.println("任務1執行");
});
CompletableFuture task2 = CompletableFuture.runAsync(()->{
System.out.println("任務2執行");
});
CompletableFuture task3 = CompletableFuture.runAsync(()->{
System.out.println("任務3執行");
});
// 等待所以任務執行完成返回
CompletableFuture.allOf(task1,task2,task3).join();
return result;
其實初步上看，這段代碼沒什么特別的，每個任務都是調用一個RPC請求。初期測試這段代碼的時候是通過IDEA啟動項目，也就是用的是 SpringBoot 內嵌 Tomcat啟動的，這段代碼功能正常。然后呢，代碼開始commit,merge。
到了第二天之后，同事測試發現這段代碼拋出了異常，而且這個功能是主入口，那么就是說大大的阻塞啊，此時我心里心情是這樣的
立馬上后臺看日志，但是卻發現這個異常是RPC內部處理時拋出來的，第一反應那就是找上游服務提供方，問他們是不是改接口啦？準備開始甩鍋！
然后結果就是沒有！！！ 于是乎我又跑了下項目，測試了一下接口，沒問題！確實沒問題！臥槽？？？還有更奇怪的事情，那就是同時裝了好幾套環境，其他環境是沒問題的，此時就沒再去關注，后來發現只有在重啟了服務器之后，這個問題就會作為必現問題，著實頭疼。
問題定位
到這里只能老老實實去debug RPC調用過程的源碼了。也就是代碼示例中寫的，RPC調用過程中，會使用ServiceLoader去找XX接口對應的實現類，而這個配置是在RPC框架的jar包中，這個jar包那自然肯定是在對應微服務的WEB-INFO/lib里了。
這段源碼大概長這樣吧：
ArrayList list = new ArrayList<String>();
ServiceLoader<T> serviceLoader = ServiceLoader.load(xxx interface);
serviceLoader.forEach(xxx->{
list.add(xxx)
});
這步執行完后，如果list是空的，那就會拋個異常，這個異常就是前面所說RPC調用過程中的異常了。
到這里，加載不到，那就要懷疑ClassLoader了，先看下ClassLoader加載范圍
Bootstrap ClassLoader
%JRE_HOME%\lib 下的 rt.jar、resources.jar、charsets.jar 和 classExtClassLoader
%JRE_HOME%\lib\ext 目錄下的jar包和classAppClassLoader
當前應用ClassPath指定的路徑中的類ParallelWebappClassLoader
這個就屬于Tomcat自定義ClassLoader了，可以加載當前應用下WEB-INFO/lib
再看下ServiceLoader的實現：
public static <S> ServiceLoader<S> load(Class<S> service) {
ClassLoader cl = Thread.currentThread().getContextClassLoader();
return ServiceLoader.load(service, cl);
}
public static <S> ServiceLoader<S> load(Class<S> service,
ClassLoader loader)
{
return new ServiceLoader<>(service, loader);
}
private ServiceLoader(Class<S> svc, ClassLoader cl) {
service = Objects.requireNonNull(svc, "Service interface cannot be null");
loader = (cl == null) ? ClassLoader.getSystemClassLoader() : cl;
acc = (System.getSecurityManager() != null) ? AccessController.getContext() : null;
reload();
}
調用load的時候，先獲取當前線程的上下文ClassLoader，然后調用new，進入到ServiceLoader的私有構造方法中，這里重點有一句 loader = (cl == null) ? ClassLoader.getSystemClassLoader() : cl; ，如果傳入的classLoader是null(null就代表是BootStrapClassLoader)，就使用ClassLoader.getSystemClassLoader()，其實就是AppClassLoader了。
然后就要確定下執行ServiceLoader.load方法時，最終ServiceLoader的loader到底是啥？
1.Debug 通過Sring Boot 內嵌Tomcat啟動的應用
在這種情況下ClassLoader是org.springframework.boot.web.embedded.tomcat.TomcatEmbeddedWebappClassLoader2.Debug 通過Tomcat啟動的應用
在這種情況下ClassLoader是AppClassLoader，通過Thread.currentThread().getContextClassLoader()獲取到的是null
真相已經快要接近，為啥同樣的代碼，Tomcat應用啟動的獲取到的線程當前上下文類加載器卻是BootStrapClassLoader呢？
問題就在于CompletableFuture.runAsync這里，這里并沒有顯示指定Executor，所以會使用ForkJoinPool線程池，而ForkJoinPool中的線程不會繼承父線程的ClassLoader。enmm,很奇妙，為啥不繼承，也不知道。。。
問題印證
下面通過例子來證實下，先從基本的看下，這里主要是看子線程會不會繼承父線程的上下文ClassLoader，先自定義一個ClassLoader,更加直觀：
class MyClassLoader extends ClassLoader{
}
測試一
private static void test1(){
MyClassLoader myClassLoader = new MyClassLoader();
Thread.currentThread().setContextClassLoader(myClassLoader);
// 創建一個新線程
new Thread(()->{
System.out.println( Thread.currentThread().getContextClassLoader());
}).start();
}
輸出
classloader.MyClassLoader@4ff782ab
測試結論： 通過普通new Thread方法創建子線程，會繼承父線程的上下文ClassLoader
*源碼分析：
查看new Thread創建線程源碼發現有如下代碼
if (security == null || isCCLOverridden(parent.getClass()))
this.contextClassLoader = parent.getContextClassLoader();
else
this.contextClassLoader = parent.contextClassLoader;
所以子線程的上下文ClassLoader會繼承父線程的上下文ClassLoader
測試二
在Tomcat容器環境下執行下述代碼
MyClassLoader myClassLoader = new MyClassLoader();
Thread.currentThread().setContextClassLoader(myClassLoader);
CompletableFuture<Void> task1 = CompletableFuture.runAsync(() -> {
System.out.println(Thread.currentThread().getContextClassLoader());
});
輸出
null
但是如果通過main函數執行上述代碼，依然是會打印出自定義類加載器
為啥呢？查了一下資料，Tomcat 默認使用SafeForkJoinWorkerThreadFactory作為ForkJoinWorkerThreadFactory，然后看下SafeForkJoinWorkerThreadFactory源碼
private static class SafeForkJoinWorkerThread extends ForkJoinWorkerThread {
protected SafeForkJoinWorkerThread(ForkJoinPool pool) {
super(pool);
this.setContextClassLoader(ForkJoinPool.class.getClassLoader());
}
}
這里發現，ForkJoinPool線程設置的ClassLoader是java.util.concurrent.ForkJoinPool的類加載器，而此類位于rt.jar包下，那它的類加載器自然就是BootStrapClassLoader了
問題解決
解決方式一：
ClassLoader contextClassLoader = Thread.currentThread().getContextClassLoader();
CompletableFuture<Void> task1 = CompletableFuture.runAsync(() -> {
Thread.currentThread().setContextClassLoader(contextClassLoader);
});
那就是在ForkJoinPool線程中再重新設置一下上下文ClassLoader
解決方式二：
CompletableFuture<Void> task1 = CompletableFuture.runAsync(() -> {
Thread.currentThread().setContextClassLoader(contextClassLoader);
},new MyExecutorService());
那就是不使用CompletableFuture的默認線程池ForkJoinPool，轉而使用我們的自定義線程池
后續補充
為什么在Tomcat中CompletableFutrue的默認線程池ForkJoinPool的threadFactory卻是SafeForkJoinWorkerThreadFactory？
1）首先查看ForkJoinPool設置ThreadFactory的地方源碼
private static ForkJoinPool makeCommonPool() {
int parallelism = -1;
ForkJoinWorkerThreadFactory factory = null;
UncaughtExceptionHandler handler = null;
try { // ignore exceptions in accessing/parsing properties
、、、、、、省略不重要代碼
String fp = System.getProperty
("java.util.concurrent.ForkJoinPool.common.threadFactory");
if (fp != null)
factory = ((ForkJoinWorkerThreadFactory)ClassLoader.
getSystemClassLoader().loadClass(fp).newInstance());
、、、、、、省略不重要代碼
} catch (Exception ignore) {
}
if (factory == null) {
if (System.getSecurityManager() == null)
factory = defaultForkJoinWorkerThreadFactory;
else // use security-managed default
factory = new InnocuousForkJoinWorkerThreadFactory();
}
、、、、、、省略不重要代碼
可以看到，如果可以從java.util.concurrent.ForkJoinPool.common.threadFactory中獲取到值，那么就使用這個值作為ThreadFactory，相當于是一個擴展。
2）那么這個值是在哪里設置進去的呢？
設置的地方就是org.apache.catalina.core.JreMemoryLeakPreventionListener。這個類實現了LifecycleListener。其中有一行代碼
if (forkJoinCommonPoolProtection && !JreCompat.isJre9Available()) {
// Don't override any explicitly set property
if (System.getProperty(FORK_JOIN_POOL_THREAD_FACTORY_PROPERTY) == null) {
System.setProperty(FORK_JOIN_POOL_THREAD_FACTORY_PROPERTY,
SafeForkJoinWorkerThreadFactory.class.getName());
}
}
可以看到就是這里的鍋。
參考
https://segmentfault.com/a/1190000022798514
http://www.lxweimin.com/p/8fcce16ae507
http://blog.itpub.net/69912579/viewspace-2658278/
https://tomcat.apache.org/tomcat-8.5-doc/config/listeners.html
https://bugs.java.com/bugdatabase/view_bug.do?bug_id=JDK-8172726
http://tomcat.apache.org/tomcat-8.5-doc/changelog.html
