1.虛擬機棧（本地變量表）引用的對象
2.方法區靜態屬性引用的對象
3.方法區常量引用的對象
4.本地方法棧JNI（一般指naive方法）中引用的對象
常說的GC(Garbage Collector) roots，特指的是垃圾收集器（Garbage Collector）的對象，GC會收集那些不是GC roots且沒有被GC roots引用的對象。
一個對象可以屬於多個root，GC root有幾下種：
- Class - 由系統類加載器(system class loader)加載的對象，這些類是不能夠被回收的，他們可以以靜態字段的方式保存持有其它對象。我們需要注意的一點就是，通過用戶自定義的類加載器加載的類，除非相應的
java.lang.Class實例以其它的某種（或多種）方式成為roots，否則它們並不是roots，. - Thread - 活着的線程
- Stack Local - Java方法的local變量或參數
- JNI Local - JNI方法的local變量或參數
- JNI Global - 全局JNI引用
- Monitor Used - 用於同步的監控對象
- Held by JVM - 用於JVM特殊目的由GC保留的對象，但實際上這個與JVM的實現是有關的。可能已知的一些類型是：系統類加載器、一些JVM知道的重要的異常類、一些用於處理異常的預分配對象以及一些自定義的類加載器等。然而，JVM並沒有為這些對象提供其它的信息，因此就只有留給分析分員去確定哪些是屬於"JVM持有"的了。
以下是一張由Java Profiler的標示出哪些是GC roots的示例圖：
作者：RednaxelaFX
鏈接：https://www.zhihu.com/question/53613423/answer/135743258
來源：知乎
著作權歸作者所有，轉載請聯系作者獲得授權。
之前看深入理解JVM這本書，對里面的GC ROOT的真實含義不是太清楚，網上查了一大堆資料都沒有說的很清楚，下面這是從知乎大神上看到的，這里面記錄一下，和大家一起學習
所謂“GC roots”，或者說tracing GC的“根集合”，就是一組必須活躍的引用。
例如說，這些引用可能包括：
Tracing GC的根本思路就是：給定一個集合的引用作為根出發，通過引用關系遍歷對象圖，能被遍歷到的（可到達的）對象就被判定為存活，其余對象（也就是沒有被遍歷到的）就自然被判定為死亡。注意再注意：tracing GC的本質是通過找出所有活對象來把其余空間認定為“無用”，而不是找出所有死掉的對象並回收它們占用的空間。
GC roots這組引用是tracing GC的起點。要實現語義正確的tracing GC，就必須要能完整枚舉出所有的GC roots，否則就可能會漏掃描應該存活的對象，導致GC錯誤回收了這些被漏掃的活對象。
這就像任何遞歸定義的關系一樣，如果只定義了遞推項而不定義初始項的話，關系就無法成立——無從開始；而如果初始項定義漏了內容的話，遞推出去也會漏內容。
那么分代式GC對GC roots的定義有什么影響呢？
答案是：分代式GC是一種部分收集（partial collection）的做法。在執行部分收集時，從GC堆的非收集部分指向收集部分的引用，也必須作為GC roots的一部分。
具體到分兩代的分代式GC來說，如果第0代叫做young gen，第1代叫做old gen，那么如果有minor GC / young GC只收集young gen里的垃圾，則young gen屬於“收集部分”，而old gen屬於“非收集部分”，那么從old gen指向young gen的引用就必須作為minor GC / young GC的GC roots的一部分。
繼續具體到HotSpot VM里的分兩代式GC來說，除了old gen到young gen的引用之外，有些帶有弱引用語義的結構，例如說記錄所有當前被加載的類的SystemDictionary、記錄字符串常量引用的StringTable等，在young GC時必須要作為strong GC roots，而在收集整堆的full GC時則不會被看作strong GC roots。
換句話說，young GC比full GC的GC roots還要更大一些。如果不能理解這個道理，那整個討論也就無從談起了。
例如說，這些引用可能包括：
- 所有Java線程當前活躍的棧幀里指向GC堆里的對象的引用；換句話說，當前所有正在被調用的方法的引用類型的參數/局部變量/臨時值。
- VM的一些靜態數據結構里指向GC堆里的對象的引用，例如說HotSpot VM里的Universe里有很多這樣的引用。
- JNI handles，包括global handles和local handles
- （看情況）所有當前被加載的Java類
- （看情況）Java類的引用類型靜態變量
- （看情況）Java類的運行時常量池里的引用類型常量（String或Class類型）
- （看情況）String常量池（StringTable）里的引用
Tracing GC的根本思路就是：給定一個集合的引用作為根出發，通過引用關系遍歷對象圖，能被遍歷到的（可到達的）對象就被判定為存活，其余對象（也就是沒有被遍歷到的）就自然被判定為死亡。注意再注意：tracing GC的本質是通過找出所有活對象來把其余空間認定為“無用”，而不是找出所有死掉的對象並回收它們占用的空間。
GC roots這組引用是tracing GC的起點。要實現語義正確的tracing GC，就必須要能完整枚舉出所有的GC roots，否則就可能會漏掃描應該存活的對象，導致GC錯誤回收了這些被漏掃的活對象。
這就像任何遞歸定義的關系一樣，如果只定義了遞推項而不定義初始項的話，關系就無法成立——無從開始；而如果初始項定義漏了內容的話，遞推出去也會漏內容。
那么分代式GC對GC roots的定義有什么影響呢？
答案是：分代式GC是一種部分收集（partial collection）的做法。在執行部分收集時，從GC堆的非收集部分指向收集部分的引用，也必須作為GC roots的一部分。
具體到分兩代的分代式GC來說，如果第0代叫做young gen，第1代叫做old gen，那么如果有minor GC / young GC只收集young gen里的垃圾，則young gen屬於“收集部分”，而old gen屬於“非收集部分”，那么從old gen指向young gen的引用就必須作為minor GC / young GC的GC roots的一部分。
繼續具體到HotSpot VM里的分兩代式GC來說，除了old gen到young gen的引用之外，有些帶有弱引用語義的結構，例如說記錄所有當前被加載的類的SystemDictionary、記錄字符串常量引用的StringTable等，在young GC時必須要作為strong GC roots，而在收集整堆的full GC時則不會被看作strong GC roots。
換句話說，young GC比full GC的GC roots還要更大一些。如果不能理解這個道理，那整個討論也就無從談起了。
Garbage Collection Roots A garbage collection root is an object that is accessible from outside the heap. The following reasons make an object a GC root: System Class Class loaded by bootstrap/system class loader. For example, everything from the rt.jar like java.util.* . JNI Local Local variable in native code, such as user defined JNI code or JVM internal code. JNI Global Global variable in native code, such as user defined JNI code or JVM internal code. Thread Block Object referred to from a currently active thread block. Thread A started, but not stopped, thread. Busy Monitor Everything that has called wait() or notify() or that is synchronized. For example, by calling synchronized(Object) or by entering a synchronized method. Static method means class, non-static method means object. Java Local Local variable. For example, input parameters or locally created objects of methods that are still in the stack of a thread. Native Stack In or out parameters in native code, such as user defined JNI code or JVM internal code. This is often the case as many methods have native parts and the objects handled as method parameters become GC roots. For example, parameters used for file/network I/O methods or reflection. Finalizable An object which is in a queue awaiting its finalizer to be run. Unfinalized An object which has a finalize method, but has not been finalized and is not yet on the finalizer queue. Unreachable An object which is unreachable from any other root, but has been marked as a root by MAT to retain objects which otherwise would not be included in the analysis. Java Stack Frame A Java stack frame, holding local variables. Only generated when the dump is parsed with the preference set to treat Java stack frames as objects. Unknown An object of unknown root type. Some dumps, such as IBM Portable Heap Dump files, do not have root information. For these dumps the MAT parser marks objects which are have no inbound references or are unreachable from any other root as roots of this type. This ensures that MAT retains all the objects in the dump 作者：秦漢郵俠 鏈接：https://www.jianshu.com/p/f4ff9fcc0759 來源：簡書 簡書著作權歸作者所有，任何形式的轉載都請聯系作者獲得授權並注明出處。
參考：
https://www.jianshu.com/p/f4ff9fcc0759