1、垃圾回收

有哪些垃圾收集算法？

在JVM（JAVA虛擬機）中，垃圾回收主要使用了以下幾種算法：

1、 標記-清除算法（Mark-Sweep）：這是最基本的垃圾回收算法。它分為兩個階段：標記階段和清除階段。在標記階段，GC會遍歷所有的對象，對所有存活的對象進行標記；在清除階段，GC會清除所有未被標記（即不再使用）的對象。這種方法的缺點是會產生大量的內存碎片。

 

 

 

2、 復制算法（Copying）：這種算法將可用內存分為兩塊，每次只使用其中一塊。當這一塊內存用完了，就將還存活的對象復制到另一塊上面，然后再把已使用過的內存空間一次清理掉。這種做法的好處是簡單且沒有內存碎片，但是代價是內存利用率低。

 

 

 

3、 標記-整理算法（Mark-Compact）：這種算法是標記-清除算法的改進版，它在標記和清除的基礎上增加了整理的過程。在標記和清除之后，它會將所有存活的對象都向一端移動，然后直接清理掉端邊界以外的內存。

 

 

 

4、 分代收集算法（Generational Collection）：這種算法的基本思想是根據對象存活的生命周期將內存劃分為幾塊。一般情況下，將堆分為新生代和老年代，這樣我們就可以根據各年代的特點選擇合適的垃圾回收算法。比如，新生代中每次垃圾回收都會有大量對象死去，只有少量存活，那就選用復制算法，只需要付出少量存活對象的復制成本就可以完成收集。而老年代中因為對象存活率高、沒有額外空間對它進行分配擔保，就必須使用標記-清理或者標記-整理算法進行回收。

以上就是JVM中常見的幾種垃圾回收算法。需要注意的是，實際的JVM實現（比如HotSpot）在實踐中會根據具體情況采用不同的垃圾回收算法，甚至是幾種算法的組合，以達到最優的垃圾回收效果。例如，HotSpot的新生代默認使用復制算法，老年代使用標記-整理算法。

知道哪幾種垃圾收集器，各自的優缺點

JVM 提供了多種垃圾收集器，每種收集器都有各自的特點和適用場景。以下是一些典型的垃圾收集器：

1、 Serial Collector：串行收集器，適用于單核 CPU 的環境。它在新生代使用復制算法，在老年代使用標記-整理算法。這種收集器在進行垃圾回收時會暫停所有的用戶線程，因此并不適用于要求低停頓時間的應用。

2、 Parallel Collector：并行收集器，也稱為吞吐量優先收集器。它在新生代使用復制算法，在老年代使用標記-整理算法。Parallel Collector 可以使用多個線程并行地執行垃圾回收任務，以提高吞吐量。但是，它在進行垃圾回收時同樣會暫停所有的用戶線程。

3、 Concurrent Mark Sweep（CMS）收集器：CMS 收集器是一種并發收集器，主要針對老年代。它在新生代使用復制算法，在老年代使用標記-清除算法。CMS 收集器的目標是減少垃圾回收引起的停頓時間。它的垃圾回收過程包括以下四個階段：

• 初始標記（Initial Mark）：標記 GC Roots 可達的老年代對象，此階段會暫停用戶線程。
• 并發標記（Concurrent Mark）：在用戶線程運行的同時，標記所有可達的老年代對象。
• 重新標記（Remark）：修正并發標記階段因用戶線程繼續運行而導致的標記變化，此階段會暫停用戶線程。
• 并發清除（Concurrent Sweep）：在用戶線程運行的同時，清除不再被引用的對象。

CMS 收集器的優點是降低了停頓時間，但缺點是對 CPU 資源要求較高，并且由于使用了標記-清除算法，可能導致內存碎片問題。

4、 G1（Garbage-First）收集器：G1 收集器是一種面向服務器應用的垃圾收集器，旨在實現高吞吐量和低停頓時間。G1 收集器將堆內存劃分為多個大小相等的區域（Region），每個區域可能是 Eden 區、Survivor 區或者 Old 區。G1 收集器在新生代使用復制算法，在老年代使用標記-整理算法。它的垃圾回收過程包括以下階段：

• 初始標記（Initial Mark）：標記 GC Roots 可達的對象，此階段會暫停用戶線程。
• 并發標記（Concurrent Mark）：在用戶線程運行的同時，標記所有可達的對象。
• 最終標記（Final Mark）：修正并發標記階段因用戶線程繼續運行而導致的標記變化，此階段會暫停用戶線程。
• 篩選回收（Evacuation）：G1 會根據回收價值和成本，選擇性地回收部分區域。將存活的對象復制到空閑區域，回收完成后，原區域變為空閑區域。此階段會暫停用戶線程。

G1 收集器的優點是在實現高吞吐量的同時，可以控制停頓時間，避免長時間的 Full GC。此外，由于 G1 使用了標記-整理算法，可以減少內存碎片問題。缺點是 G1 收集器對系統資源要求較高，可能導致各個階段的 CPU 和內存開銷增加。

總結： CMS 和 G1 收集器都是為了實現低停頓時間的垃圾收集。CMS 收集器主要針對老年代，使用標記-清除算法，可能導致內存碎片問題。G1 收集器通過將堆劃分為多個區域并使用標記-整理算法，既實現了低停頓時間，又解決了內存碎片問題。盡管這兩種收集器都能提高應用程序的響應性，但它們對系統資源的要求較高，可能導致吞吐量下降。選擇合適的垃圾收集器需要根據應用程序的具體需求和資源限制進行權衡。

G1垃圾回收器的一些重要參數

 

 

 

G1（Garbage-First）垃圾回收器是一種面向服務器的垃圾回收器，主要用于多核處理器和大內存環境。G1垃圾回收器以高預測性的停頓時間，及高整體吞吐量為設計目標。以下是一些G1垃圾回收器的重要參數：

1、 -XX:+UseG1GC：啟用G1垃圾回收器。

2、 -XX:MaxGCPauseMillis：設置G1垃圾回收期間的最大停頓時間（以毫秒為單位）。G1垃圾回收器將盡力保證實際停頓時間不超過這個值。

3、 -XX:G1HeapRegionSize：設置G1的堆區域大小。G1將堆劃分為多個相等的區域，這個參數用于設置每個區域的大小。其值應是1M到32M之間，并且是2的冪。

4、
-XX:InitiatingHeapOccupancyPercent：設置啟動并發標記周期的堆占用百分比。當老年代的占用率超過這個值時，就會啟動并發標記周期。默認值是45。

5、 -XX:G1ReservePercent：設置作為備用的堆內存百分比，用于在并發周期結束時確保有足夠的空閑空間。默認值是10。

6、 -XX:ParallelGCThreads：設置并行垃圾回收的線程數。默認值與CPU的數量相同。

7、 -XX:ConcGCThreads：設置并發垃圾回收的線程數。默認值是ParallelGCThreads的1/4。

8、 -XX:G1NewSizePercent：設置新生代最小值占整個Java堆的百分比，G1會根據運行時的情況動態調整新生代的大小，但不會低于G1NewSizePercent設置的值。默認值是5%。

9、 -XX:G1MaxNewSizePercent：設置新生代最大值占整個Java堆的百分比，默認值是60%。

10、 -XX:G1MixedGCCountTarget：設置混合垃圾回收的目標次數，即在并發周期結束后，還可以進行多少次混合垃圾回收。默認值是8。

以上是一些G1垃圾回收器的重要參數，每個參數都可以通過JVM啟動時的命令行參數進行設置。在實際使用時，需要根據應用程序的特性和運行環境的情況，調整這些參數的值，以獲取最好的垃圾回收性能。

怎么設置垃圾回收器和參數

這些參數的設置通常是在啟動JVM時作為命令行參數傳入的。如果是使用Spring Boot的話，可以在java -jar命令后面添加這些參數。

假設有一個Spring Boot的應用，它的JAR包名為my-App.jar，想使用G1垃圾回收器，并設置最大的垃圾收集停頓時間為200毫秒，可以這樣設置：

java -XX:+UseG1GC -XX:MaxGCPauseMillis=200 -jar my-app.jar

在這個例子中，-XX:+UseG1GC啟用了G1垃圾回收器，-XX:MaxGCPauseMillis=200設置了最大的垃圾收集停頓時間為200毫秒。

這些設置是針對單個JVM實例的，也就是說，它們只影響正在啟動的那個Java應用。如果在一臺服務器上運行了多個Java應用，需要為每個應用分別設置這些參數。

如果希望在一臺服務器上統一設置這些參數，可能需要創建一個啟動腳本，然后在這個腳本中為所有的Java應用指定相同的參數。但是，請注意，不是所有的應用都需要相同的參數設置，不同的應用可能有不同的性能特性和需求。因此，在實際操作中，可能需要根據每個應用的特性和需求，適當地調整這些參數的值。

新生代，老年代，永久代，元空間 的區別

在Java虛擬機（JVM）中，堆內存是用于存放Java對象的地方，它被劃分為不同的區域或"代"，這些代基于對象的生命周期進行劃分。以下是這些代的詳細解釋：

1、 新生代（Young Generation）：新創建的對象首先被放置在新生代。新生代又被劃分為一個Eden區和兩個Survivor區（通常被稱為Survivor From和Survivor To）。大部分情況下，對象在Eden區中被創建，然后通過幾輪的垃圾收集（Minor GC）在Survivor區之間移動。如果一個對象在新生代中存活時間足夠長（達到一定的年齡閾值），它就會被晉升（promote）到老年代。

2、 老年代（Old Generation）：長時間存活的對象，或者已經從新生代晉升過來的對象會被存放在老年代。老年代中的垃圾收集被稱為Major GC，它的發生頻率通常比Minor GC低，但每次收集的時間通常較長。

3、 永久代（Permanent Generation）：在Java 7及更早的版本中，JVM使用永久代來存儲類的元數據，如類的名稱、字段和方法等。請注意，永久代并不是Java堆的一部分，因此它有自己的內存空間限制。永久代中的垃圾收集被稱為Full GC。

4、 元空間（Metaspace）：在Java 8中，永久代被元空間所替代。和永久代不同，元空間并不在物理上存在于Java堆中，因此，它不受Java堆大小的限制，而是受系統的實際內存大小限制。元空間主要用于存儲類的元數據。

這就是Java堆中各個區域的基本概念。它們的主要目標是優化垃圾收集性能，因為不同的垃圾收集器可以根據對象的生命周期和區域的特性采用不同的策略。

對象是怎么從年輕代進入老年代的？

在Java虛擬機（JVM）中，新創建的對象首先會被分配到新生代（Young Generation）的Eden區。當Eden區滿了之后，就會觸發一次Minor GC（小型垃圾回收）。

在Minor GC中，JVM會清理掉Eden區中無用（不再被引用）的對象，并將還存活（仍然被引用）的對象轉移到Survivor區。Survivor區包括兩部分，S0和S1，一開始，所有存活的對象會被復制到其中一個Survivor區（如S0）。

在下一次Minor GC時，Eden區和已經占用的Survivor區（如S0）中仍然存活的對象會被復制到另一個Survivor區（如S1），并清空Eden區和第一個Survivor區（如S0）。

這個過程每次Minor GC都會重復進行，Survivor區中的對象在每次Minor GC后如果仍然存活，并且年齡（即被復制的次數）達到一定閾值（默認15次，可通過-XX:MaxTenuringThreshold參數調整），那么這個對象就會被晉升到老年代（Old Generation）。

此外，如果Survivor區無法容納在一次Minor GC中Eden區和另一個Survivor區（如S0）中存活下來的對象，或者大對象（大于Survivor區一半的對象）直接分配不進Survivor區，這些對象也會直接被分配到老年代。

所以，一個對象從新生代進入老年代，要么是因為它的年齡達到了閾值，要么是因為Survivor區無法容納它，或者它是一個大對象。

CMS分為哪幾個階段?（CMS已經棄用，不必深究）

CMS（Concurrent Mark Sweep）垃圾回收器是一種以獲取最短回收停頓時間為目標的垃圾回收器。它主要針對老年代進行垃圾回收。CMS垃圾回收過程大致分為以下四個階段：

1、 初始標記（Initial Mark）：這個階段是"Stop The World"階段，也就是說在這個階段，應用線程會被暫停以允許垃圾收集器線程工作。在這個階段，垃圾收集器會標記所有從GC Roots直接可達的對象。

2、 并發標記（Concurrent Mark）：在此階段，垃圾收集器會在應用線程運行的同時，遍歷所有從GC Roots可達的對象。由于在此階段應用線程和垃圾收集器線程并發運行，因此這個階段不需要停止應用線程。

3、 重新標記（Remark）：這個階段也是"Stop The World"階段。由于在并發標記階段，應用線程和垃圾收集器線程是并發運行的，因此可能會有一些引用關系發生了改變的對象沒有被正確標記。重新標記階段的目的就是修正這些標記錯誤。

4、 并發清除（Concurrent Sweep）：在此階段，垃圾收集器會清除那些被標記為垃圾的對象。這個階段也是在應用線程運行的同時進行的，不需要停止應用線程。

CMS垃圾回收器的主要目標是盡可能減少"Stop The World"的時間，以達到減少應用的響應時間的目標。但是，CMS垃圾回收器也有一些缺點，比如它無法處理浮動垃圾，可能會導致內存碎片化，以及在并發清除階段可能會與應用線程競爭CPU等。因此，在選擇使用CMS垃圾回收器時，需要根據應用的特性和需求進行權衡。

CMS都有哪些問題？

CMS (Concurrent Mark Sweep) 垃圾回收器是一種以獲取最短回收停頓時間為目標的垃圾回收器。雖然 CMS 回收器在降低停頓時間方面做得很好，但也存在一些問題和挑戰：

1、 內存碎片化：CMS 采用的是標記-清除的算法，這種算法會導致內存空間碎片化。清理出來的空間可能是不連續的，當需要分配大對象時，無法找到足夠的連續內存，會觸發 Full GC。

2、 浮動垃圾問題：在 CMS GC 的并發清理階段，應用線程還在運行并且可能產生新的垃圾，這部分垃圾稱為浮動垃圾。由于 CMS 并發清理階段之后并沒有其他的 STW 操作，所以這部分浮動垃圾只能等到下一次 GC 時進行清理。

3、 并發階段可能會導致應用線程變慢：CMS 的收集線程在并發階段會和應用線程一起占用 CPU，如果 CPU 資源緊張，可能會導致應用線程運行速度變慢。

4、 對 CPU 資源敏感：CMS 默認啟動的回收線程數是 (CPU數量+3)/4，當 CPU 核數較多時，CMS 并發執行的回收線程數也就多，這樣可能會對應用產生較大的影響。

5、 無法處理晉升失敗：如果在 Minor GC 期間，Survivor 空間不足以容納新晉升的對象，這些對象會直接晉升到老年代，如果老年代也無法容納這些對象，就會出現晉升失敗（promotion fAIled）。CMS 無法處理晉升失敗，只能觸發 Full GC。

由于以上問題，Java 9 中引入了另一種低延遲的垃圾回收器，叫做 G1（Garbage First）垃圾回收器，它克服了 CMS 的一些問題，例如內存碎片化和處理晉升失敗等。

JVM垃圾回收時候如何確定垃圾？什么是GC Roots？

在JVM中，判斷一個對象是否為"垃圾"，主要依據的是該對象是否還被引用。如果一個對象沒有任何引用指向它，那么這個對象就可以被認為是垃圾，可以被垃圾收集器回收。

然而，在實際操作中，直接查找每個對象的引用情況是非常低效的，因此，JVM采用了一種反向的思路來判斷對象是否為垃圾，這就涉及到了"GC Roots"的概念。

GC Roots（垃圾回收根節點）是一組必須活躍的引用，垃圾收集器在進行垃圾收集時，會從GC Roots開始，遍歷這些根節點，然后通過引用鏈的方式，查找出所有從GC Roots開始可以訪問到的對象，這些對象被認為是"非垃圾"對象。反之，那些從GC Roots開始無法通過引用鏈訪問到的對象，就被認為是"垃圾"，可以被回收。

常見的GC Roots對象包括：

1、 虛擬機棧（棧幀中的本地變量表）中引用的對象：也就是當前線程的局部變量和輸入參數。

2、 方法區中類靜態屬性引用的對象：這些是類的靜態變量。

3、 方法區中常量引用的對象：這些是被final修飾的常量。

4、 本地方法棧中JNI（即通常說的Native方法）引用的對象。

以上這些都作為GC Roots，JVM從這些節點出發，通過引用關系，找出所有被引用的對象，未被引用的對象就被視為是可回收的垃圾。

能夠找到 Reference Chain 的對象，就一定會存活么？

一般來說，從GC Roots開始可以通過引用鏈找到的對象，都是可達的（reachable），這些對象不會被垃圾回收器視為垃圾進行回收。這是因為它們可能還會在程序運行過程中被使用，因此需要保留。

然而，這并不意味著所有可達的對象都是"活動的"或"需要的"。在某些情況下，一些實際上不再需要的對象可能仍然是可達的，這種情況通常被稱為"內存泄漏"（Memory Leak）。例如，如果一個集合對象（如ArrayList或HashMap）在全局范圍內可達，并且一直在添加新的元素，但是這些元素在被添加之后就不再被使用，那么這些元素實際上是不需要的，但是它們仍然是可達的，因此不會被垃圾回收器回收，這就造成了內存泄漏。

此外，Java還提供了弱引用（Weak Reference）、軟引用（Soft Reference）和虛引用（Phantom Reference）這三種特殊的引用類型，這些引用類型所指向的對象即使是可達的，也可能被垃圾回收器回收。這為處理那些需要通過某種方式與垃圾收集器進行交互的復雜場景提供了可能性。

總的來說，從GC Roots開始可以通過引用鏈找到的對象，通常都是存活的，不會被垃圾回收器回收，但是這并不絕對。在某些特殊情況下，這些對象可能仍然會被回收，或者可能因為內存泄漏等問題而需要被手動處理。

新生代，老年代，永久代，元空間 內存分配占比多少

這些區域的默認內存占比并非固定，而是依賴于JVM的具體實現以及配置。但在HotSpot虛擬機中，一種常見的默認配置是：

1、 新生代（Young Generation）：新生代通常占據堆的1/3。新創建的對象首先被放置在新生代。新生代又被劃分為一個Eden區和兩個Survivor區（Survivor From和Survivor To）。通常默認配置是Eden區占新生代的8/10，兩個Survivor區各占新生代的1/10。

2、 老年代（Old Generation）：老年代通常占據堆的2/3。長時間存活的對象，或者已經從新生代晉升過來的對象會被存放在老年代。

3、 永久代（Permanent Generation）：在Java 7及更早的版本中，JVM使用永久代來存儲類的元數據，如類的名稱、字段和方法等。永久代的默認大小根據具體的JVM實現和配置而變，但通常不會太大。

4、 元空間（Metaspace）：在Java 8中，永久代被元空間所替代。元空間并不在物理上存在于Java堆中，因此，它不受Java堆大小的限制，而是受系統的實際內存大小限制。元空間主要用于存儲類的元數據。

這只是一種常見的默認配置，并且可以根據應用的需求來調整這些區域的大小。例如，如果應用創建了大量的短暫的小對象，可能想要增加新生代的大小；如果應用需要加載大量的類，可能想要增加永久代或元空間的大小。

JVM 中一次完整的 GC 流程是怎樣的，對象如何晉升到老年代

一次完整的 GC 流程涉及到 Java 堆內存的劃分以及不同類型的垃圾回收。以下是詳細的解釋：

1、 Java 堆內存劃分：

Java 堆內存被劃分為新生代（Young Generation）和老年代（Old Generation）。新生代包括 Eden 區和兩個 Survivor 區（S0 和 S1）。新創建的對象首先分配在 Eden 區，經過一定次數的垃圾回收后，存活的對象會被移動到 Survivor 區，最后晉升到老年代。

2、 Minor GC：

Minor GC（小型垃圾回收）主要發生在新生代。當 Eden 區的空間不足以分配新的對象時，Minor GC 會被觸發。Minor GC 的主要任務是清理 Eden 區中不再被引用的對象，并將存活的對象移動到 Survivor 區（S0 或 S1）。如果 Survivor 區已滿，那么達到一定年齡閾值的對象會被晉升到老年代。Minor GC 通常比較快，因為新生代的大部分對象生命周期較短。

3、 Major GC：

Major GC（大型垃圾回收）主要發生在老年代。當老年代的空間不足以存儲晉升的對象時，Major GC 會被觸發。與 Minor GC 不同，Major GC 需要回收整個老年代區域，包括長時間存活的對象和不再被引用的對象。Major GC 通常比 Minor GC 要慢很多，因為需要回收更多的內存區域。

4、 Full GC：

Full GC（全面垃圾回收）是一種涉及整個堆內存的垃圾回收，包括新生代、老年代和元空間（Java 8 開始，替代了持久代）。Full GC 通常在以下情況下觸發：

• 老年代空間不足以存儲晉升的對象。
• 元空間內存不足以加載新的類。
• JVM 參數顯式觸發 Full GC。
• 系統調用 System.gc() 方法。

Full GC 的開銷相對較大，因為它需要回收整個堆內存和元空間。在進行 Full GC 期間，應用程序的吞吐量會受到影響，因此應盡量避免 Full GC 的發生。

5、 轉化流程：

• 新創建的對象首先分配在 Eden 區。
• Minor GC：當 Eden 區空間不足時，發生 Minor GC，將存活對象從 Eden 區移動到 Survivor 區（S0 或 S1）。
• 晉升：當對象在 Survivor 區達到一定年齡閾值時，它們會被晉升到老年代。年齡閾值可以通過 JVM 參數 -XX:MaxTenuringThreshold 進行設置。
• Major GC：當老年代空間不足以存儲晉升的對象時，發生 Major GC，回收整個老年代區域。
• Full GC：在一些特殊情況下，如老年代空間不足、元空間內存不足、系統調用 System.gc() 方法等，會觸發 Full GC，回收整個堆內存和元空間。

為了減少 GC 開銷并提高應用程序性能，可以通過調整 JVM 參數來優化堆內存的劃分以及垃圾回收策略。例如，可以根據對象的生命周期和內存使用情況調整新生代、老年代和元空間的大小。此外，可以選擇適當的垃圾回收器，如 G1、CMS 或 Parallel GC，以滿足特定應用場景的需求。

MinorGC，MajorGC、FullGC都什么時候發生？

在Java虛擬機（JVM）中，垃圾收集（GC）主要有Minor GC、Major GC和Full GC三種。下面是它們各自發生的情況：

1、 Minor GC：Minor GC主要在新生代（Young Generation）中發生。當新生代的Eden區（其中存放新創建的對象）滿時，就會觸發Minor GC。Minor GC會清理掉Eden區無用的對象，并將還存活的對象轉移到Survivor區。如果Survivor區也滿了，那么存活的對象會被移動到老年代（Old Generation）。

2、 Major GC：Major GC主要在老年代中發生。當老年代空間不足時，就會觸發Major GC。Major GC的執行時間通常比Minor GC要長，因為需要清理的對象更多。在Major GC發生時，JVM通常會暫停所有的應用線程，因此也被稱為STW（Stop The World）。

3、 Full GC：Full GC是對整個堆（包括新生代和老年代）進行清理。當系統在進行Full GC時，所有的應用線程都會被暫停。Full GC的觸發條件比較多，包括老年代空間不足、永久代空間不足（Java 8之前）、顯式調用System.gc()、上一次GC之后Heap的剩余空間不足等。Full GC的執行時間最長，應當盡可能減少Full GC的發生。

注意：GC的性能影響和JVM的具體垃圾收集器（如Serial、Parallel、CMS、G1等）有關，不同的垃圾收集器在GC過程中的行為和性能可能會有所不同。所以在實際使用中，需要根據應用的實際情況選擇合適的垃圾收集器，以達到最好的性能效果。

jdk默認垃圾收集器是啥

Java的默認垃圾回收器（Garbage Collector, GC）根據JDK的版本和是否是服務器版有所不同。

• JDK 8以及更早的版本：默認的垃圾回收器是并行（Parallel）垃圾回收器。這是一個以吞吐量優化為目標的垃圾回收器，它在垃圾回收時會停止所有的應用線程。
• JDK 9和JDK 10：默認的垃圾回收器是G1（Garbage First）垃圾回收器。G1垃圾回收器旨在以更可預測的暫停時間提供高性能。
• JDK 11及以上：在某些特定的配置中，JDK 11及更高版本的默認垃圾回收器是G1。但是，請注意，隨著新的垃圾回收器，如ZGC（Z Garbage Collector）和Shenandoah的引入，這可能會有所改變，具體取決于JDK發行版和配置。

、 可以通過以下命令來檢查Java應用程序正在使用哪種垃圾回收器：

java -XX:+PrintCommandLineFlags -version

在這個命令的輸出中，-XX:+Use*GC標志將告訴哪種垃圾回收器正在被使用（*表示垃圾回收器的名稱）。例如，如果看到-XX:+UseG1GC，那么Java應用程序就是在使用G1垃圾回收器。

這些信息可能會隨著JDK的不同版本和配置有所變化，因此，建議檢查JDK發行版的具體文檔，以獲取最準確的信息。

GC日志的real、user、sys是什么意思？

在Java的垃圾收集（GC）日志中，real、user、sys都是用來衡量時間的指標，它們的含義如下：

1、 real：這是實際經過的墻鐘時間。也就是說，從垃圾收集開始到垃圾收集結束所經過的真實時間。

2、 user：這是所有運行在用戶模式下的CPU時間的總和。這包括了垃圾收集線程在用戶模式下運行的時間。

3、 sys：這是在內核模式下運行的CPU時間的總和。當Java進程需要執行諸如內存分配之類的系統調用時，它會切換到內核模式。

在理想情況下，我們希望real時間與user和sys時間的總和接近，因為這意味著垃圾收集線程能夠充分利用CPU資源。如果real時間遠大于user和sys時間的總和，那么可能說明垃圾收集線程在等待某些資源，比如內存或者磁盤IO。

另外，如果sys時間占總時間的比例過高，那么可能說明系統調用的開銷過大，這可能是由于頻繁的內存分配或者其他的系統調用引起的。

需要注意的是，這些時間指標都是近似值，可能會受到操作系統的調度策略和其他因素的影響。

2、內存

JVM有哪些內存區域？(JVM的內存布局是什么？)

 

 

JVM（Java 虛擬機）內存模型描述了 Java 程序在運行過程中如何使用內存。JVM 內存模型主要包括以下部分：

1、 方法區（Method Area）

方法區用于存儲已加載的類信息（如類名、訪問修飾符、常量池等）、靜態變量和常量。方法區是所有線程共享的資源。

可能存在的問題：如果加載了過多的類或者常量池過大，可能導致方法區內存耗盡，拋出
java.lang.OutOfMemoryError: PermGen space（Java 7 及之前）或
java.lang.OutOfMemoryError: Metaspace（Java 8 及之后）異常。

2、 堆（Heap）

堆是 JVM 運行時數據區的主要部分，用于存儲對象實例和數組。堆是線程共享的資源，它被劃分為年輕代（Young Generation）和老年代（Old Generation）。年輕代包括一個 Eden 區和兩個 Survivor 區（S0 和 S1），用于存儲新創建的對象。當對象在 Eden 區達到一定年齡后，它們會被移到 Survivor 區或老年代。老年代用于存儲存活時間較長的對象。

可能存在的問題：如果創建了過多的對象或者對象沒有被及時回收，可能導致堆內存耗盡，拋出
java.lang.OutOfMemoryError: Java heap space 異常。

 

 

 

3、 棧（Stack）

棧用于存儲局部變量、方法調用和返回地址等信息。每個線程都有一個獨立的棧，用于存儲該線程的方法調用棧幀。當一個方法被調用時，一個新的棧幀被壓入棧中；當方法返回時，相應的棧幀被彈出。

可能存在的問題：如果存在過深的方法調用鏈或者遞歸調用，可能導致棧內存耗盡，拋出
java.lang.StackOverflowError 異常。

4、 本地方法棧（Native Method Stack）

本地方法棧用于存儲本地方法（native 方法）的調用信息。每個線程都有一個獨立的本地方法棧。

可能存在的問題：與棧類似，本地方法棧也可能因為過深的方法調用鏈或者遞歸調用導致內存耗盡，拋出
java.lang.StackOverflowError 或
java.lang.OutOfMemoryError 異常。

5、 程序計數器（Program Counter Register）

程序計數器用于存儲當前線程正在執行的字節碼指令的地址。每個線程都有一個獨立的程序計數器。如果當前線程正在執行的是 Java 方法，程序計數器記錄的是正在執行的虛擬機字節碼指令的地址；如果當前線程正在執行的是本地方法，則程序計數器的值為 undefined。

可能存在的問題：程序計數器本身不容易出現問題，因為它的內存分配和回收是隨線程的創建和銷毀自動進行的。但程序計數器關聯的字節碼指令可能會導致一些問題，例如：死循環、跳轉到錯誤的指令地址等。這些問題需要通過檢查代碼邏輯來解決。

JVM 內存模型中的各個模塊都承擔著特定的功能和責任。為了避免內存問題，需要合理地分配和管理內存資源。例如，可以通過調整 JVM 參數來設置堆內存大小、年輕代和老年代的比例等。同時，也需要關注代碼邏輯，避免不必要的遞歸調用、死循環、內存泄漏等問題，從而確保程序的穩定運行。

Java的內存模型是什么？（JMM是什么？）

Java 內存模型（Java Memory Model, JMM）是一個抽象的概念，它定義了 Java 程序如何在內存中存儲、操作和傳遞數據。Java 內存模型主要關注以下幾個方面：

1、 原子性（Atomicity）：原子性是指一個操作要么完全執行，要么完全不執行。Java 內存模型確保了基本的讀、寫和賦值操作是原子性的。但對于 64 位數據類型（如 long 和 double），JMM 允許非原子性的讀寫操作，可能導致數據的不一致。

2、 可見性（Visibility）：可見性是指一個線程對共享變量的修改能夠被其他線程及時看到。Java 內存模型通過使用內存屏障（memory barrier）和定義一系列的內存訪問規則來確保線程之間的可見性。

3、 順序性（Ordering）：順序性是指程序在執行過程中遵循代碼的順序進行。但是，為了優化性能，編譯器、處理器和運行時系統可能對代碼進行重排序。Java 內存模型通過定義一定的順序規則來確保在多線程環境下，代碼的執行不會導致錯誤的結果。

4、 一致性（Consistency）：一致性是指程序在執行過程中，對內存中的數據操作遵循一定的規則和順序。Java 內存模型通過定義先行發生（happens-before）規則來確保內存操作的一致性。先行發生規則定義了兩個操作之間的偏序關系，使得在多線程環境下，可以預測操作的執行順序。

Java 內存模型主要關注多線程環境下的內存操作行為。它提供了一套規則和原則，以確保程序在多線程環境中的正確性、可靠性和可預測性。了解 Java 內存模型對于編寫高效且正確的多線程程序至關重要，尤其是在處理線程同步和數據共享時。

什么情況下會發生棧內存溢出

棧內存溢出（StackOverflowError）是一種運行時錯誤，通常發生在程序中存在過深的方法調用或者遞歸調用導致棧空間耗盡。

1、 棧定義：

棧（Stack）是一種后進先出（LIFO）的數據結構，用于存儲局部變量、方法調用和返回地址等信息。在 Java 程序中，每個線程都有一個棧，用于存儲該線程的方法調用棧幀。當一個方法被調用時，一個新的棧幀被壓入棧中；當方法返回時，相應的棧幀被彈出。棧幀中包含了方法的局部變量、臨時數據和方法返回地址等信息。

2、 為什么會發生棧內存溢出：

棧內存溢出通常是由于以下原因導致的：

• 過深的方法調用：如果程序中存在過深的方法調用鏈，可能導致棧空間耗盡。
• 遞歸調用：如果遞歸調用沒有正確的終止條件或終止條件設置不當，可能導致無限遞歸，從而導致棧空間耗盡。

當棧空間不足以容納更多的棧幀時，就會發生棧內存溢出錯誤。

3、 相關配置參數：

在 Java 虛擬機（JVM）中，可以通過一些參數配置線程棧的大小。以下是一些常見的參數：

• -Xss：設置每個線程棧的大小。例如，-Xss512k 將棧大小設置為 512KB。增加棧大小可以減輕棧內存溢出的風險，但也會增加內存使用量，可能導致內存不足。
• -XX:ThreadStackSize：這是一個 HotSpot JVM 特定參數，與 -Xss 類似，用于設置線程棧的大小。

調整這些參數可以影響棧空間的大小，但請注意，增加棧大小并不能解決代碼中存在的棧內存溢出問題，而只是減輕了風險。為了避免棧內存溢出，需要審查代碼以確保遞歸調用有正確的終止條件，同時避免過深的方法調用鏈。

JVM 內存模型的相關知識了解多少，比如重排序，內存屏障，happen-before，主內存，工作內存。

JVM 內存模型（Java Memory Model，JMM）主要涉及到并發編程中的一些重要概念，如重排序、內存屏障、happens-before、主內存和工作內存等。以下是這些概念的詳細解釋：

1、 重排序：為了提高程序執行的效率，編譯器和處理器可能會對指令進行重新排序。但是，在多線程環境中，指令的重排序可能會導致意料之外的結果。

2、 內存屏障：內存屏障（Memory Barrier）是一種硬件指令，用于防止指令重排序。它可以保證屏障之前的指令不會被排在屏障之后，屏障之后的指令不會被排在屏障之前。

3、 happens-before：這是一種偏序關系，用于描述程序中的兩個操作的順序。如果操作 A happens-before 操作 B，那么 A 的結果對 B 是可見的，且 A 不會被重排序到 B 之后。

4、 主內存和工作內存：在 JMM 中，所有的變量都存儲在主內存中，每個線程還有自己的工作內存，用于保存主內存中變量的副本。線程對變量的所有操作都在工作內存中進行，然后再同步回主內存。

現在，我們通過一個 volatile 關鍵字的例子來解釋這些概念：

public class VolatileDemo {
    volatile int i = 0;

    public void update() {
        i++;
    }
}

在這個例子中，i 是一個 volatile 變量。當我們在多線程環境中調用 update 方法時，以下是發生的事情：

• 由于 i 是 volatile 變量，所以每次讀取 i 的值都會直接從主內存中獲取，每次寫入 i 的值都會立即同步回主內存。這保證了 volatile 變量在所有線程中的可見性。
• volatile 變量的寫操作 happens-before 任何后續的讀操作。這意味著，如果一個線程寫入 volatile 變量并且此后另一個線程讀取該 volatile 變量，那么第一個線程寫入 volatile 變量時的所有可見的共享變量，在第二個線程讀取 volatile 變量后都將保持一致。
• 對于 volatile 變量，編譯器和處理器不會進行重排序。實際上，volatile 寫入操作后面會插入一個寫屏障（Write Barrier），防止寫操作被重排序到屏障之后；volatile 讀操作前面會插入一個讀屏障（Read Barrier），防止讀操作被重排序到屏障之前。這確保了 volatile 變量的順序一致性。

這個例子展示了如何使用 volatile 關鍵字來保證變量在多線程環境中的可見性和順序一致性。但需要注意的是，volatile 不能保證復合操作的原子性。在上述例子中，i++ 是一個復合操作，包括讀取 i 的值、對 i 加一和寫入 i 的新值三個步驟。盡管 volatile 可以保證每個步驟的可見性和順序一致性，但是在多線程環境中，這三個步驟仍然可能被其他線程的操作打斷，導致 i++ 操作的結果不正確。要保證復合操作的原子性，我們需要使用同步機制，如 synchronized 關鍵字或 java.util.concurrent 包中的原子類。

總的來說，JVM 內存模型定義了 Java 程序在多線程環境中如何正確、安全地訪問共享變量。理解 JMM 中的重排序、內存屏障、happens-before、主內存和工作內存等概念，對于編寫高效、可靠的并發程序至關重要。

JVM 內存為什么要分成新生代，老年代，持久代。新生代中為什么要分為 Eden 和 Survivor。

JVM 內存中的堆（Heap）主要用于存儲對象實例和數組。為了提高內存管理的效率，JVM 將堆內存劃分為新生代（Young Generation）、老年代（Old Generation）和持久代（PermGen，Java 8 開始被元空間 MetaSpace 替代）。這種劃分基于分代收集算法，它根據對象的生命周期對內存進行分區管理。分代收集算法的核心思想是：大部分對象生命周期較短，只有少部分對象存活時間較長。

1、 Java 堆：

Java 堆是 JVM 內存中的主要部分，用于存儲對象實例和數組。它被劃分為新生代和老年代。

2、 新生代劃分：

新生代是 Java 堆的一部分，主要用于存儲新創建的對象。新生代被進一步劃分為 Eden 區和兩個 Survivor 區（S0 和 S1）。

• Eden 區：新創建的對象首先分配在 Eden 區。
• Survivor 區：Survivor 區有兩個，S0 和 S1。它們用于存儲從 Eden 區晉升的存活對象。

3、 轉化和參數配置：

當新生代中的對象經過一定次數的垃圾回收后（即對象達到一定年齡），這些對象會被移動到老年代。這個過程稱為晉升（Promotion）。

以下是一些與新生代相關的 JVM 參數：

• -Xmn：設置新生代的大小。
• -XX:NewRatio：設置老年代和新生代的比例。
• -XX:SurvivorRatio：設置 Eden 區和 Survivor 區的比例。

4、 為什么要劃分新生代、老年代和持久代：

這種劃分主要是為了提高垃圾回收的效率。根據對象的生命周期，大部分對象很快就不再被引用并且可以被回收。只有少數對象需要長期保留。這種觀察結果導致了分代收集算法的產生。

新生代用于存放新創建的對象，垃圾收集器主要關注新生代。由于新生代中的大部分對象生命周期較短，可以快速回收。頻繁進行新生代的垃圾回收可以有效減少老年代的垃圾回收次數，提高垃圾回收效率。

將 Eden 區和 Survivor 區分開的主要原因是為了解決對象在新生代中的內存碎片問題。通過在 Survivor 區之間來回復制對象，可以避免內存碎片的產生，同時減少內存整理的開銷。

老年代用于存放長時間存活的對象。

什么情況會造成元空間溢出？

Java的元空間（Metaspace）用于存儲加載到內存中的類的元數據信息，如類名、訪問修飾符、常量池、字段描述、方法描述等。元空間在Java 8中取代了之前版本的永久代（PermGen）。

元空間的大小并不是固定的，而是根據需要動態地從本地內存中分配空間。默認情況下，元空間的大小只受限于本地內存的大小。但是，我們可以通過-XX:MetaspaceSize和-XX:MaxMetaspaceSize參數來設置元空間的初始大小和最大大小。

以下是一些可能導致元空間溢出的情況：

1、 加載過多的類：如果應用程序加載了大量的類，可能會使元空間填滿。這種情況可能在使用大型框架或者服務器容器的應用中出現，因為這些應用可能會加載大量的類。也可能在動態生成并加載類的應用中出現，比如某些腳本語言的Java實現。

2、 類加載器泄漏：在Java中，類的生命周期是和加載它們的類加載器（ClassLoader）綁定的。當一個類加載器被回收時，它加載的所有類也會被卸載。因此，如果一個類加載器沒有被回收（比如被某些對象引用了），它加載的所有類也會一直存在，這可能會導致元空間溢出。

3、 設置的最大元空間大小太小：如果使用了-XX:MaxMetaspaceSize參數，并且設置的值太小，也可能會導致元空間溢出。

出現元空間溢出時，JVM會拋出
java.lang.OutOfMemoryError: Metaspace錯誤。為了解決這個問題，我們需要分析應用程序的類加載情況，找出為什么會加載過多的類或者類加載器沒有被回收。此外，也可以考慮增大最大元空間大小，但是這可能會增大應用程序的內存占用。

什么時候會造成堆外內存溢出？

在Java中，堆外內存（Off-Heap Memory）主要是指不由Java虛擬機（JVM）直接管理的內存。一般來說，有以下幾種情況可能導致堆外內存溢出：

1、 直接內存使用過多：在Java中，我們可以通過
java.nio.ByteBuffer.allocateDirect()方法分配直接內存（Direct Memory）。直接內存不是由JVM的垃圾回收器管理的，因此，如果我們分配了過多的直接內存，并且沒有及時釋放，可能會導致堆外內存溢出。注意，直接內存的大小默認和Java堆的最大大小一樣，可以通過-XX:MaxDirectMemorySize參數來設置。

2、 JNI使用過多的內存：Java本地接口（Java Native Interface，JNI）允許Java代碼調用本地方法，這些本地方法可能會分配額外的內存。如果這些本地方法分配了過多的內存，并且沒有及時釋放，也可能會導致堆外內存溢出。

3、 線程過多：每個線程在被創建時，都會有一個線程棧被分配。線程棧的大小默認是1MB（這個大小可以通過-Xss參數設置）。因此，如果創建了過多的線程，可能會導致堆外內存溢出。

4、 類元數據區域使用過多：在Java 8及以上版本中，類的元數據（如類的名字、字段和方法等信息）被存儲在Metaspace中。Metaspace默認使用的是堆外內存，如果加載了過多的類，可能會導致Metaspace使用過多的內存，從而導致堆外內存溢出。注意，Metaspace的大小默認是不限制的，但是可以通過-XX:MaxMetaspaceSize參數來設置。

以上就是可能導致堆外內存溢出的一些常見情況。要解決這些問題，我們需要對JVM的內存管理有深入的了解，同時也需要使用一些工具和技巧來排查和解決問題。

有什么堆外內存的排查思路？

堆外內存是指在Java虛擬機（JVM）管理的堆內存之外的內存。以下是一些排查堆外內存問題的思路：

1、 確認是否存在堆外內存問題：首先，我們需要確認是否存在堆外內存問題。比如，我們可以通過查看操作系統的進程內存使用情況，比較JVM的堆內存和進程的總內存使用情況，來判斷是否有大量的堆外內存被使用。

2、 分析堆外內存的使用情況：如果確認存在堆外內存問題，那么我們就需要分析堆外內存的使用情況。常見的堆外內存使用包括直接內存（Direct Memory，通過ByteBuffer.allocateDirect分配）、線程棧、類元數據區（Metaspace或PermGen）、JNI代碼等。我們可以使用工具（如jmap、jconsole、VisualVM、MAT等）或JVM參數（如-XX:NativeMemoryTracking、-XX:+PrintFlagsFinal等）來分析這些區域的內存使用情況。

3、 定位具體的內存使用位置：在得到了內存使用的概況之后，我們需要進一步定位具體的內存使用位置。這可能需要分析代碼，查找可能使用了大量堆外內存的地方。比如，我們可以查找是否有大量的DirectByteBuffer被創建但沒有被釋放，或者是否有大量的線程被創建等。

4、 解決問題：在找到了問題的位置之后，我們就可以嘗試解決問題。比如，我們可以嘗試減少DirectByteBuffer的使用，或者優化線程的使用等。如果問題出在JNI代碼上，可能需要修改或優化JNI代碼。

5、 持續監控：在解決問題之后，我們需要持續監控內存使用情況，確認問題已經被解決，并防止未來出現類似的問題。

總的來說，排查堆外內存問題需要對JVM的內存管理有深入的了解，同時也需要使用一些工具和技巧。并且，由于堆外內存的管理比較復雜，所以排查和解決問題可能需要一定的時間和精力。

為什么要將堆內存分區？

Java的堆內存被分為不同的區域，包括年輕代（Young Generation）、老年代（Old Generation）和元空間（Metaspace，JDK 8引入，替代了之前版本中的永久代）。這種分區的設計主要基于兩個觀察結果：

1、 大部分對象都是短暫存在的：這是由Peter Denning在他的論文"The Working Set Model for Program Behavior"中提出的弱分代假說得出的結論。也就是說，新創建的大部分對象都會很快變成垃圾，比如方法中的臨時變量。因此，通過將新創建的對象放在年輕代中，可以快速回收這些短暫存在的對象，從而避免了全堆的垃圾收集。

2、 短暫存在的對象和長時間存在的對象可能有不同的垃圾收集需求：對于短暫存在的對象，我們需要一種能夠快速回收大量對象的垃圾收集算法。對于長時間存在的對象，我們需要一種能夠有效處理內存碎片化的垃圾收集算法。通過將堆內存分區，我們可以針對不同區域的特性選擇最合適的垃圾收集算法。

除此之外，將堆內存分區還可以減少垃圾收集時的暫停時間。因為進行一次全堆的垃圾收集可能需要停止所有的應用線程，這可能導致應用的響應時間過長。通過只對堆內存的一部分進行垃圾收集，可以減少每次垃圾收集時的暫停時間。

以上就是將Java堆內存分區的主要原因。通過這種方式，Java虛擬機可以更有效地管理內存，提高垃圾收集的性能，以及提供更穩定的應用響應時間。

3、調優

說說知道的幾種主要的 JVM 參數

JVM 提供了大量的參數用于配置和調優，以下是一些主要的 JVM 參數：

1、 堆內存配置相關的參數：

• -Xms：設置 JVM 最小堆大小。例如，-Xms256m 表示最小堆大小為 256MB。
• -Xmx：設置 JVM 最大堆大小。例如，-Xmx1024m 表示最大堆大小為 1024MB。
• -Xmn：設置年輕代大小。例如，-Xmn512m 表示年輕代大小為 512MB。
• -XX:PermSize 和 -XX:MaxPermSize：設置永久代大小。這兩個參數在 Java 8 及以后的版本已經被 Metaspace 參數所取代。
• -XX:MetaspaceSize 和 -XX:MaxMetaspaceSize：在 Java 8 及以后的版本中，設置元空間（Metaspace）的初始大小和最大大小。

2、 垃圾收集器相關的參數：

• -XX:+UseSerialGC：設置 JVM 使用 Serial 垃圾收集器。
• -XX:+UseParallelGC：設置 JVM 使用 Parallel 垃圾收集器。
• -XX:+UseConcMarkSweepGC：設置 JVM 使用 CMS 垃圾收集器。
• -XX:+UseG1GC：設置 JVM 使用 G1 垃圾收集器。
• -XX:ParallelGCThreads：設置 Parallel 和 G1 垃圾收集器的線程數。
• -XX:ConcGCThreads：設置 CMS 垃圾收集器的線程數。

3、 性能調優和故障排查相關的參數：

• -XX:+PrintGC：打印簡單的垃圾收集信息。
• -XX:+PrintGCDetails：打印詳細的垃圾收集信息。
• -XX:+PrintGCTimeStamps：在垃圾收集信息中包含時間戳。
• -XX:+HeapDumpOnOutOfMemoryError：在發生內存溢出時生成堆轉儲文件（heap dump）。
• -XX:HeapDumpPath：設置堆轉儲文件的路徑。

以上只是 JVM 參數的一部分，JVM 提供了大量的參數用于調優和故障排查。在實際使用中，應根據應用的需求和運行環境來選擇和配置這些參數。

JVM 調優的步驟

JVM調優主要分為以下幾個步驟：

1、 確定目標：首先，需要確定調優的目標。是要減少系統的暫停時間（例如，減少垃圾收集的時間），還是提高系統的吞吐量（例如，每秒鐘處理的任務數量），或者其他。不同的目標可能需要采取不同的調優策略。

2、 監控和分析：接下來，使用JVM提供的各種工具進行監控和分析，如VisualVM、jstat、jconsole等。這些工具可以幫助我們了解JVM的運行情況，例如堆內存的使用情況，垃圾收集的情況等。

3、 識別問題：分析監控數據，找出可能的性能瓶頸或問題，如頻繁的垃圾收集，內存泄漏，CPU使用率過高等。

4、 調整參數：根據識別的問題，調整JVM的參數，如選擇合適的垃圾收集器，調整堆內存的大小，新生代和老年代的比例等。這個過程可能需要多次嘗試，以找到最優的參數配置。

5、 測試和驗證：修改參數后，進行壓力測試和性能測試，驗證修改是否達到了預期的效果。如果效果不理想，可能需要返回步驟4，再次調整參數。

6、 持續監控：調優后，需要持續監控JVM的運行情況，因為隨著應用的運行，系統的運行環境可能會變化，可能需要再次進行調優。

JVM調優是一個復雜的過程，需要深入理解JVM的工作原理和應用的運行情況。在進行調優時，一定要小心謹慎，避免因為不恰當的調優而導致系統性能下降。

一般什么時候考慮 JVM 調優呢？

JVM 調優通常在以下幾種情況下考慮：

1、 內存溢出或內存泄漏：這是最常見的需要進行 JVM 調優的場景。當出現 OutOfMemoryError 錯誤，或者系統內存使用量持續上升，可能是內存溢出或內存泄漏問題。這時需要調整 JVM 參數，如堆內存大小，新生代和老年代的比例等，同時需要定位并修復內存泄漏問題。

2、 系統響應速度慢：如果系統的響應速度慢，可能是因為垃圾收集器頻繁的 Full GC，導致系統暫停時間過長。這時可以考慮調整垃圾收集器設置或更換垃圾收集器，以減少 Full GC 的發生。

3、 CPU 使用率高：如果 CPU 使用率過高，可能是因為垃圾收集器的工作過于頻繁。這時需要考慮調整 JVM 參數，以減輕垃圾收集的壓力。

4、 系統吞吐量低：如果系統的吞吐量（每秒鐘處理的任務數量）低，可能是因為 JVM 的配置不合理。這時需要根據系統的實際需求和運行環境，調整 JVM 參數，以提高系統的吞吐量。

5、 應用啟動慢：如果應用的啟動時間過長，可能是因為類加載器加載類的過程過慢，或者初始化堆內存大小設置過大，導致垃圾收集器在啟動時進行大量的內存回收。這時可以調整類加載器的設置，或者調整堆內存的初始大小，以提高應用的啟動速度。

在進行 JVM 調優時，一定要根據系統的實際需求和運行環境，結合 JVM 的性能監控和分析工具，進行合理的參數設置。同時，要注意調優是一個持續的過程，需要根據系統的運行情況不斷進行調整。

強引用、軟引用、弱引用、虛引用是什么？

在Java中，根據對象的可達性（可訪問性）和回收性，引用被分為四種類型：強引用（Strong Reference）、軟引用（Soft Reference）、弱引用（Weak Reference）和虛引用（Phantom Reference）。以下是四種引用類型的區別和示例：

1、 強引用（Strong Reference）：這是程序中最常見的普通對象引用，只要強引用還存在，垃圾收集器就永遠不會回收掉被引用的對象。

Object obj = new Object();

2、 軟引用（Soft Reference）：軟引用關聯的對象，在系統內存充足時不會被回收，只有在系統內存不足時才會被回收。軟引用通常用于實現內存敏感的緩存。

Object obj = new Object();
SoftReference<Object> softRef = new SoftReference<>(obj);
obj = null; // 使 obj 成為軟引用

3、 弱引用（Weak Reference）：無論當前內存空間足夠與否，只要垃圾收集器線程掃描到弱引用關聯的對象，就會回收這個對象。弱引用常常用于 Map 數據結構中的鍵（key），這樣可以自動去除不再使用的鍵值對。

Object obj = new Object();
WeakReference<Object> weakRef = new WeakReference<>(obj);
obj = null; // 使 obj 成為弱引用

4、 虛引用（Phantom Reference）：虛引用關聯的對象，有可能被垃圾收集器回收，也有可能不被回收，但是，我們不能通過虛引用訪問到對象的任何屬性或函數。所以，虛引用必須和引用隊列（ReferenceQueue）聯合使用。虛引用的主要用途是跟蹤對象被垃圾回收器回收的活動，當某個對象被回收時，JVM 會把這個虛引用加入到與之關聯的引用隊列中。

ReferenceQueue<Object> refQueue = new ReferenceQueue<>();
Object obj = new Object();
PhantomReference<Object> phantomRef = new PhantomReference<>(obj, refQueue);
obj = null; // 使 obj 成為虛引用

注意，上述示例中，通過 obj = null; 語句斷開了強引用，使得對象只被軟引用、弱引用或虛引用關聯。否則，由于強引用的存在，對象將不會被垃圾收集器回收。

簡單說說了解的類加載器，可以打破雙親委派么，怎么打破。

類加載器（ClassLoader）是 Java 運行時系統的一部分，負責在運行時查找和加載類文件到 JVM 中。在 Java 中，類加載器主要有以下幾種：

1、 啟動類加載器（Bootstrap ClassLoader）：是 JVM 自身的一部分，由 C++ 實現，負責加載 JAVA_HOME/lib 目錄下的核心類庫（如 rt.jar）。 2、 擴展類加載器（Extension ClassLoader）：由 Java 實現，負責加載 JAVA_HOME/lib/ext 目錄下的類庫。 3、 系統類加載器（System ClassLoader）：也稱為應用類加載器，由 Java 實現，負責加載用戶類路徑（ClassPath）上的類庫。

這三種類加載器之間的關系形成了一個稱為 "雙親委派模型"（Parent Delegation Model）的層次結構。當一個類需要被加載時，系統類加載器會首先將這個任務委托給其父類加載器，也就是擴展類加載器；擴展類加載器再委托給啟動類加載器。如果啟動類加載器找不到這個類，就會返回給擴展類加載器；如果擴展類加載器也找不到，就會返回給系統類加載器。只有當父類加載器無法完成這個加載任務時，才由自身去加載。

雙親委派模型的主要目的是為了確保 Java 核心庫的類型安全。這樣，類即使在類路徑中存在，也是由啟動類加載器進行加載。這種方式保證了由不同類加載器最終加載該類都是同一份字節碼。

但是，在某些情況下，我們可能需要打破雙親委派模型。例如，對于一些熱替換（Hot Deployment）的功能，可能會需要自定義類加載器。為了實現這種功能，可以通過重寫類加載器的 loadClass 方法來打破雙親委派模型。

@Override
protected Class<?> loadClass(String name, boolean resolve) throws ClassNotFoundException {
    // 首先，檢查該類是否已經被加載過
    Class<?> c = findLoadedClass(name);
    if (c == null) {
        try {
            // 嘗試用自己的類加載器加載
            c = findClass(name);
        } catch (ClassNotFoundException e) {
            // 如果自己的類加載器加載失敗，再委托給父類加載器
            c = super.loadClass(name, resolve);
        }
    }
    return c;
}

上述代碼中，我們首先嘗試用自己的類加載器加載類，如果失敗，再委托給父類加載器。這樣就打破了傳統的雙親委派模型。

怎么打出線程棧信息

在 Java 中，可以通過幾種方式打出線程棧信息：

1、 使用 jstack 命令：jstack 是 JDK 自帶的一種命令行工具，可以用來生成當前時刻的線程快照。線程快照是線程活動的一種表示，它對于分析線程問題（如死鎖）有很大的幫助。下面是 jstack 命令的基本用法：

jstack [pid]

其中，[pid] 是 Java 進程的 PID。可以通過 jps 命令找到 Java 進程的 PID。

2、 使用 kill -3 命令：在 Unix/linux 系統中，可以向 Java 進程發送 SIGQUIT 信號（即 kill -3）來生成線程快照。線程快照會被打印到標準錯誤流（stderr）或者由 -XX:OnOutOfMemoryError 參數指定的命令的輸出中。

kill -3 [pid]

3、 在 Java 代碼中使用 Thread.dumpStack() 方法：這個方法可以打印當前線程的棧信息到標準錯誤流（stderr）。

以下是一個簡單的例子，演示如何使用 jstack 命令排查線程問題：

假設的 Java 應用在運行過程中出現了性能問題，懷疑是因為某個線程的 CPU 使用率過高。可以使用 top -H -p [pid] 命令找出 CPU 使用率最高的線程，然后使用 printf "%xn" [tid] 命令將線程的 TID（線程 ID）轉換為十六進制的格式。然后，可以在 jstack [pid] 命令的輸出中查找這個十六進制的 TID，找到對應的線程棧信息。通過分析線程棧信息，可以找出這個線程正在執行的代碼，從而定位到問題的原因。

safepoint是什么？

"Safepoint"是Java HotSpot虛擬機中的一個術語。在執行一些全局性的操作（比如垃圾收集）時，Java虛擬機需要確保所有的線程都處于一種可知的、可控的狀態，這種狀態就是"Safepoint"。在Safepoint中，所有執行Java字節碼的線程都會暫停，直到全局性的操作完成。

具體到HotSpot虛擬機，當它需要執行一些必須暫停所有線程的操作時（比如某種類型的垃圾收集），它會設置一個"Safepoint"。一旦設置了"Safepoint"，所有正在執行的線程會在下一個"Safepoint"檢查點時暫停。線程可以在執行一些特定的字節碼、調用方法、異常處理等地方設置檢查點。一旦線程到達這些檢查點，就會檢查是否設置了"Safepoint"。如果設置了"Safepoint"，線程就會進入阻塞狀態，等待全局性的操作完成。

需要注意的是，這個過程可能會導致應用的暫停，即所謂的"Stop-The-World"（STW）。STW會導致應用的響應時間增加，因此在設計和優化垃圾收集器時，通常會盡量減少STW的時間。

invokedynamic指令是干什么的？

invokedynamic是Java 7引入的一條新的字節碼指令，這條指令為Java提供了動態類型（dynamic typing）的能力。在此之前，Java的方法調用都是靜態類型的，也就是說，在編譯時期就能確定方法的調用者和被調用的方法。invokedynamic指令打破了這個限制，允許在運行時動態地確定方法的調用者和被調用的方法。

invokedynamic指令的主要目的是為了支持在JVM上運行的動態類型語言，如Groovy、JRuby、Jython等。在這些語言中，方法的調用者和被調用的方法經常需要在運行時才能確定，這就需要動態類型的支持。

invokedynamic指令的工作方式與Java中其他的方法調用指令（如invokevirtual、invokeinterface等）有所不同。它不直接調用目標方法，而是通過所謂的調用點（call site）和方法句柄（method handle）。調用點是由一個引導方法（bootstrap method）初始化的，這個引導方法會返回一個方法句柄，這個方法句柄引用了真正要調用的方法。當invokedynamic指令執行時，它會通過調用點得到方法句柄，然后通過方法句柄調用目標方法。

這種設計提供了極大的靈活性，使得JVM可以有效地支持各種動態類型語言。此外，Java 8引入的Lambda表達式也使用了invokedynamic指令來實現。

棧幀都有哪些數據？

在Java虛擬機（JVM）中，每當一個方法被調用時，JVM都會為這個方法創建一個新的棧幀（Stack Frame）。每個棧幀都包含了一些用于支持方法調用和方法執行的數據。以下是棧幀中的主要組成部分：

1、 局部變量表（Local Variable Array）：這部分存儲了方法的所有局部變量，包括方法的參數和方法內部定義的局部變量。局部變量表的大小在編譯時確定，單位為slot，不會在方法執行過程中改變。

2、 操作數棧（Operand Stack）：這是一個后入先出（LIFO）的棧，用于存儲方法執行過程中的臨時數據。比如，在計算表達式的值時，會先把操作數壓入操作數棧，然后執行操作，最后把結果壓入操作數棧。

3、 動態鏈接（Dynamic Linking）：這部分用于支持方法調用過程中的動態鏈接。每個棧幀都包含一個指向運行時常量池中該棧幀所屬方法的引用，持有這個引用是為了支持動態鏈接。

4、 方法返回地址（Return Address）：當一個方法被調用時，需要在方法結束后返回到調用它的地方繼續執行。這個返回地址就是方法調用者的PC計數器的值。

5、 附加信息（Additional Information）：可能還包含一些其他的信息，比如用于支持異常處理的信息等。

以上就是JVM中棧幀的主要組成部分。每個棧幀都對應一個正在執行的方法調用，這些棧幀在Java虛擬機棧中形成一個棧，用于支持Java程序的方法調用和方法執行。

Java的雙親委托機制是什么？

雙親委托模型（Parent Delegation Model）是Java類加載器（ClassLoader）在加載類時使用的一種模型。

在Java中，類加載器是用來加載類的工具。每一個類都是由一個類加載器加載的，而類加載器之間存在層級關系。在雙親委托模型中，如果一個類加載器收到了類加載的請求，它首先不會自己去加載，而是把這個請求委托給父類加載器去完成，每一個層次的類加載器都是如此，因此所有的加載請求最終都應該傳送到頂層的啟動類加載器（Bootstrap ClassLoader）中。只有當父類加載器反饋自己無法完成這個加載請求（它的搜索范圍中沒有找到所需的類）時，子加載器才會嘗試自己去加載。

雙親委托模型的主要優點是：

1、 避免類的重復加載：由于所有的加載請求都交給了頂層，因此類在被加載時不會被其他的加載器再次加載，保證了Java對象的唯一性。

2、 保護了Java核心API的穩定性：Java核心庫的類由啟動類加載器加載，其他的類加載器不會加載這些類。這樣就防止了惡意代碼替換Java核心庫，保護了Java核心API的穩定性。

雙親委托模型是Java類加載器的默認模型。然而，這并不是一個強制性的模型，如果有特殊需要，可以創建自定義的類加載器，打破這個模型。例如，Java的SPI（Service Provider Interface）機制，就需要打破雙親委托模型，由線程的上下文類加載器去加載服務提供者的實現類。

JIT是什么？

JIT（Just-In-Time）編譯器是Java虛擬機的一部分，負責將字節碼轉換為可以直接在特定硬件和操作系統上運行的機器碼。這種在運行時進行編譯的技術被稱為“即時編譯”。

Java程序的運行過程一般分為兩個階段：解釋執行和編譯執行。Java源代碼首先被編譯成字節碼，然后由JVM解釋執行這些字節碼。雖然字節碼可以跨平臺運行，但是解釋執行的效率相對較低。

為了提高執行效率，JVM引入了JIT編譯器。JIT編譯器會監視運行的Java程序，找出經常執行（即“熱點代碼”）的部分，然后將這些字節碼編譯成機器碼。這樣，當這些代碼再次執行時，JVM就可以直接執行機器碼，從而大大提高了執行效率。

JIT編譯器還會進行一些優化，比如方法內聯、循環展開、常量折疊等，進一步提高執行效率。

因此，JIT編譯器是JVM提高Java程序運行效率的一個重要工具。通過將字節碼編譯成機器碼，并進行各種優化，JIT編譯器使得Java程序的運行速度可以接近，甚至在某些情況下超過，編譯型語言（如C++）的程序。

什么是方法內聯？

方法內聯（Method Inlining）是一種編譯器優化技術，主要用于減少方法調用的開銷。當一個方法被調用時，會有一些額外的運行時開銷，比如建立新的棧幀、保存和恢復寄存器的值、跳轉到方法的入口點等。通過方法內聯，編譯器可以將方法的體直接插入到調用它的地方，從而避免這些開銷。

例如，假設我們有如下的代碼：

void methodA() {
    methodB();
}

void methodB() {
    // do something
}

通過方法內聯，上述代碼可以被優化為：

void methodA() {
    // do something
}

Java的即時編譯器（JIT）在運行時會進行方法內聯。JIT會根據運行時的性能數據（比如方法的調用頻率）來決定哪些方法需要內聯。通常來說，頻繁調用的小方法是內聯的好候選者。

需要注意的是，方法內聯并不總是提高性能。如果一個方法很大，或者被內聯的方法的數量過多，可能會導致編譯后的代碼太大，從而影響指令緩存的效率。因此，Java的JIT編譯器會使用一些啟發式方法來決定何時以及如何進行方法內聯。

Java虛擬機調用字節碼指令有哪些？

Java虛擬機（JVM）使用的是基于棧的架構，其核心是一組字節碼指令集。字節碼是Java編譯器編譯Java源代碼后的產物，每一條字節碼指令都對應一個操作碼（opcode）。下面是一些常見的字節碼指令分類：

1、 加載和存儲指令：這類指令用于在局部變量表和操作數棧之間移動數據。例如，iload、aload、istore、astore等。

2、 算術指令：這類指令用于執行基本的算術運算，如加法、減法、乘法、除法等。例如，iadd、isub、imul、idiv等。

3、 類型轉換指令：這類指令用于將兩種不同的數值類型進行相互轉換。例如，i2l、i2d、l2i等。

4、 對象創建與訪問指令：這類指令用于創建對象、數組，以及訪問對象的字段和數組的元素。例如，new、getfield、putfield、getstatic、putstatic、newarray等。

5、 操作數棧管理指令：這類指令用于直接操作操作數棧，包括將常量壓入棧、彈出棧頂元素、復制棧頂元素等。例如，iconst、pop、dup等。

6、 控制轉移指令：這類指令用于控制流程的轉移，包括條件和無條件的跳轉、方法調用和返回等。例如，ifeq、ifne、goto、invokevirtual、invokestatic、invokespecial、invokeinterface、invokedynamic、return等。

7、 異常處理指令：這類指令用于異常的拋出。例如，athrow。

8、 同步指令：這類指令用于多線程同步。例如，monitorenter、monitorexit。

每種指令都有自己的操作語義，而且很多指令都有自己的操作數，這些操作數提供了額外的信息，比如要加載或存儲的局部變量的索引，要跳轉的目標地址等。這個字節碼指令集使得Java具有跨平臺的能力，因為JVM可以在任何支持的平臺上解釋執行這些字節碼。

Java當中的常量池

在Java中，常量池（Constant Pool）是Java虛擬機（JVM）的一部分，主要用于存儲常量信息。常量池的主要任務是為Java類提供變量和方法的引用。每個加載的類（包括類和接口等）以及每個Java方法都有一個常量池。

常量池主要包括以下幾種常量：

1、 類和接口常量：包含了對一個類或接口的全限定名的引用。

2、 字段引用：包含了字段的類、名稱和類型的引用。

3、 方法引用：包含了方法的類、方法名稱和方法描述符的引用。

4、 字符串常量：Java字符串直接量就是存儲在常量池中的。

5、 數值常量：包括整數（Integer）、浮點數（Float）、長整型（Long）和雙精度浮點型（Double）。

6、 方法類型和方法句柄：這是Java 7引入的，主要是為了支持動態類型語言。

在Java 7及之前的版本中，常量池是存儲在方法區中的，而在Java 8及以后的版本中，由于方法區被移除，常量池被移動到了元空間（Metaspace）中。

常量池有以下幾個特點：

• 常量池具有動態性：雖然常量池中的數據在編譯期間就已經產生，但并不意味著在編譯后就固定不變。Java語言規定，如果一個字符串是第一次被創建，那么會在常量池中創建一個字符串對象，如果字符串已經在常量池中存在，那么不會創建新的對象，而是返回已經存在的對象的引用。
• 常量池能提高性能和節省內存：由于常量池的存在，讓一些相同的常量可以共享同一塊內存，避免了重復創建和存儲，從而可以提高性能和節省內存。
• 常量池是每個類或接口的運行時常量池：常量池是在編譯期被創建，但在運行期被加載到JVM中的。每個加載到JVM中的類或接口都有一個常量池，即使這些類或接口的常量池中包含相同的常量，這些常量也是屬于不同的常量池。