Java多執行緒程式設計-（9）-ThreadLocal造成OOM記憶體溢位案例演示與原理分析
原文出自 : https://blog.csdn.net/xlgen157387/article/details/78298840
案例程式碼
1、首先看一下程式碼，模擬了一個執行緒數為500的執行緒池，所有執行緒共享一個ThreadLocal變數，每一個執行緒執行的時候插入一個大的List集合：
import java.util.ArrayList;
import java.util.List;
import java.util.concurrent.ExecutorService;
import java.util.concurrent.Executors;
public
- 1
- 2
- 3
- 4
- 5
- 6
- 7
- 8
- 9
- 10
- 11
- 12
- 13
- 14
- 15
- 16
- 17
- 18
- 19
- 20
- 21
- 22
- 23
- 24
- 25
- 26
- 27
- 28
- 29
- 30
- 31
- 32
- 33
- 34
- 35
- 36
- 37
- 38
- 39
- 40
- 41
- 42
- 43
- 44
- 45
- 46
- 47
- 48
- 49
- 50
- 51
- 52
- 53
- 54
2、設定JVM引數設定最大記憶體為256M，以便模擬出OOM：
3、執行程式碼，輸出結果：
可以看出，單執行緒池執行到第212的時候，就報了錯誤，出現OOM記憶體溢位錯誤。
4、在執行程式碼的時候，同時開啟JDK工具jconsole 監控記憶體變化：
可以看出，上述記憶體一直遞增到JVM設定的最大值，然後丟擲異常，程式退出。
5、這個例項可以很好的演示了：執行緒池的一個執行緒使用完ThreadLocal物件之後，再也不用，由於執行緒池中的執行緒不會退出，執行緒池中的執行緒的存在，同時ThreadLocal變數也會存在，佔用記憶體！造成OOM溢位！
ThreadLocal為什麼會記憶體洩漏
在上一篇的時候，已經簡單的介紹了不正當的使用ThreadLocal造成OOM的原因，下邊詳細的介紹一下：
1、首先看一下ThreadLocal的原理圖：
Thread、ThreadLocal、ThreadLocalMap、Entry之間的關係：
上圖中描述了：一個Thread中只有一個ThreadLocalMap，一個ThreadLocalMap中可以有多個ThreadLocal物件，其中一個ThreadLocal物件對應一個ThreadLocalMap中一個的Entry（也就是說：一個Thread可以依附有多個ThreadLocal物件）。
在ThreadLocal的生命週期中，都存在這些引用。看下圖: 實線代表強引用，虛線代表弱引用。
2、ThreadLocal的實現是這樣的：每個Thread 維護一個 ThreadLocalMap 對映表，這個對映表的 key 是 ThreadLocal例項本身，value 是真正需要儲存的 Object。
3、也就是說 ThreadLocal 本身並不儲存值，它只是作為一個 key 來讓執行緒從 ThreadLocalMap 獲取 value。值得注意的是圖中的虛線，表示 ThreadLocalMap 是使用 ThreadLocal 的弱引用作為 Key 的，弱引用的物件在 GC 時會被回收。
4、ThreadLocalMap使用ThreadLocal的弱引用作為key，如果一個ThreadLocal沒有外部強引用來引用它，那麼系統 GC 的時候，這個ThreadLocal勢必會被回收，這樣一來，ThreadLocalMap中就會出現key為null的Entry，就沒有辦法訪問這些key為null的Entry的value，如果當前執行緒再遲遲不結束的話，這些key為null的Entry的value就會一直存在一條強引用鏈：Thread Ref -> Thread -> ThreaLocalMap -> Entry -> value永遠無法回收，造成記憶體洩漏。
5、總的來說就是，ThreadLocal裡面使用了一個存在弱引用的map, map的型別是ThreadLocal.ThreadLocalMap. Map中的key為一個threadlocal例項。這個Map的確使用了弱引用，不過弱引用只是針對key。每個key都弱引用指向threadlocal。 當把threadlocal例項置為null以後，沒有任何強引用指向threadlocal例項，所以threadlocal將會被gc回收。
但是，我們的value卻不能回收，而這塊value永遠不會被訪問到了，所以存在著記憶體洩露。因為存在一條從current thread連線過來的強引用。只有當前thread結束以後，current thread就不會存在棧中，強引用斷開，Current Thread、Map value將全部被GC回收。最好的做法是將呼叫threadlocal的remove方法，這也是等會後邊要說的。
6、其實，ThreadLocalMap的設計中已經考慮到這種情況，也加上了一些防護措施：在ThreadLocal的get(),set(),remove()的時候都會清除執行緒ThreadLocalMap裡所有key為null的value。這一點在上一節中也講到過！
7、但是這些被動的預防措施並不能保證不會記憶體洩漏：
（1）使用static的ThreadLocal，延長了ThreadLocal的生命週期，可能導致記憶體洩漏。
（2）分配使用了ThreadLocal又不再呼叫get(),set(),remove()方法，那麼就會導致記憶體洩漏，因為這塊記憶體一直存在。
- 1
- 2
為什麼使用弱引用，OOM是否是弱引用的鍋？
1、從表面上看記憶體洩漏的根源在於使用了弱引用。網上的文章大多著重分析ThreadLocal使用了弱引用會導致記憶體洩漏，但是另一個問題也同樣值得思考：為什麼使用弱引用而不是強引用？
我們先來看看官方文件的說法：
To help deal with very large and long-lived usages, the hash table entries use WeakReferences for keys.
為了應對非常大和長時間的用途，雜湊表使用弱引用的 key。
- 1
- 2
下面我們分兩種情況討論：
（1）key 使用強引用：引用的ThreadLocal的物件被回收了，但是ThreadLocalMap還持有ThreadLocal的強引用，如果沒有手動刪除，ThreadLocal不會被回收，導致Entry記憶體洩漏。
（2）key 使用弱引用：引用的ThreadLocal的物件被回收了，由於ThreadLocalMap持有ThreadLocal的弱引用，即使沒有手動刪除，ThreadLocal也會被回收。value在下一次ThreadLocalMap呼叫set、get、remove的時候會被清除。
比較兩種情況，我們可以發現：由於ThreadLocalMap的生命週期跟Thread一樣長，如果都沒有手動刪除對應key，都會導致記憶體洩漏，但是使用弱引用可以多一層保障：弱引用ThreadLocal不會記憶體洩漏，對應的value在下一次ThreadLocalMap呼叫set、get、remove的時候會被清除。
因此，ThreadLocal記憶體洩漏的根源是：由於ThreadLocalMap的生命週期跟Thread一樣長，如果沒有手動刪除對應key就會導致記憶體洩漏，而不是因為弱引用。
ThreadLocal 最佳實踐
1、綜合上面的分析，我們可以理解ThreadLocal記憶體洩漏的前因後果，那麼怎麼避免記憶體洩漏呢？
答案就是：每次使用完ThreadLocal，都呼叫它的remove()方法，清除資料。
在使用執行緒池的情況下，沒有及時清理ThreadLocal，不僅是記憶體洩漏的問題，更嚴重的是可能導致業務邏輯出現問題。所以，使用ThreadLocal就跟加鎖完要解鎖一樣，用完就清理。
注意：
並不是所有使用ThreadLocal的地方，都在最後remove（），他們的生命週期可能是需要和專案的生存週期一樣長的，所以要進行恰當的選擇，以免出現業務邏輯錯誤！但首先應該保證的是ThreadLocal中儲存的資料大小不是很大！
2、那麼我們修改最開始的程式碼為：
取消註釋：threadLocal.remove(); 結果不會出現OOM，可以看出堆記憶體的變化呈現鋸齒狀，證明每一次remove()之後，ThreadLocal的記憶體釋放掉了！執行緒池中的執行緒的數量持續增加！
import java.util.ArrayList;
import java.util.List;
import java.util.concurrent.ExecutorService;
import java.util.concurrent.Executors;
public class ThreadLocalOOMDemo {
private static final int THREAD_LOOP_SIZE = 500;
private static final int MOCK_DIB_DATA_LOOP_SIZE = 10000;
private static ThreadLocal<List<User>> threadLocal = new ThreadLocal<>();
public static void main(String[] args) throws InterruptedException {
ExecutorService executorService = Executors.newFixedThreadPool(THREAD_LOOP_SIZE);
for (int i = 0; i < THREAD_LOOP_SIZE; i++) {
executorService.execute(() -> {
threadLocal.set(new ThreadLocalOOMDemo().addBigList());
Thread t = Thread.currentThread();
System.out.println(Thread.currentThread().getName());
threadLocal.remove(); //模擬每次使用完之後都要呼叫remove()掉，記住是在當前執行緒內部呼叫
});
try {
Thread.sleep(1000L);
} catch (InterruptedException e) {
e.printStackTrace();
}
}
executorService.shutdown();
}
private List<User> addBigList() {
List<User> params = new ArrayList<>(MOCK_DIB_DATA_LOOP_SIZE);
for (int i = 0; i < MOCK_DIB_DATA_LOOP_SIZE; i++) {
params.add(new User("xuliugen", "password" + i, "男", i));
}
return params;
}
class User {
private String userName;
private String password;
private String sex;
private int age;
public User(String userName, String password, String sex, int age) {
this.userName = userName;
this.password = password;
this.sex = sex;
this.age = age;
}
}
}
- 1
- 2
- 3
- 4
- 5
- 6
- 7
- 8
- 9
- 10
- 11
- 12
- 13
- 14
- 15
- 16
- 17
- 18
- 19
- 20
- 21
- 22
- 23
- 24
- 25
- 26
- 27
- 28
- 29
- 30
- 31
- 32
- 33
- 34
- 35
- 36
- 37
- 38
- 39
- 40
- 41
- 42
- 43
- 44
- 45
- 46
- 47
- 48
- 49
- 50
- 51
- 52
- 53
- 54
取消註釋：threadLocal.remove(); 結果不會出現OOM，可以看出堆記憶體的變化呈現鋸齒狀，證明每一次remove()之後，ThreadLocal的記憶體釋放掉了！執行緒池中的執行緒的數量持續增加！
參考文章：
1、http://www.importnew.com/22039.html