最近，我在Java應用程序服務器安裝上進行了分析/調整，以識別瓶頸并修復它們。 在此過程中（調整），最常見的操作是在系統加載時檢索許多線程轉儲。 請記住，重載（在某些情況下）可能會產生副作用，可能會導致我們得出錯誤的結論。 因此，“控制”負載比實際重負載更可取。
當系統處于加載狀態時，您會注意到許多Java線程處于RUNNABLE狀態，但它們并未真正運行。 他們正在等待“ 某物 ”。
導致線程即使處于RUNNABLE狀態也要等待的最常見原因如下：
- CPU資源不足 ：當運行的線程多于虛擬CPU時，上下文切換，內核，OS作業和系統的其他進程會有延遲是正常的。
- RAM不足 ：如果您的RAM不足，則您的系統將使用swap，這總是一個問題。
- I / O ：當線程處于read（）或write（）調用中并等待數據寫入或讀取時，該線程處于RUNNABLE狀態，但實際上并未運行。
- 網絡慢 ：這與＃3有關，因為網絡慢得多，它將導致與網絡操作有關的“正在運行”線程的較長延遲。
- 流程優先級 ：流程可以具有不同的優先級。 如果JVM進程以低優先級運行，則其他進程將在CPU中更頻繁地運行。 您可以使用top （GNU Linux）， prstat （Solaris）， 任務管理器 （Windows）之類的工具來執行此操作。
- 垃圾收集（GC） ：運行GC時，JVM的所有線程（GC線程除外）在某些地方（世界停止）都處于凍結狀態。 在這些時候，GC正在刪除無用的引用對象，因此釋放了堆的可用內存大小（但僅限于此）。 我們必須使用這樣的策略（例如CMS或G1），以最小化停靠點的頻率和持續時間。
完全由JVM引起的唯一原因是最后一個（GC活動）。 所有其他方面主要取決于操作系統和硬件。 因此，我們還必須始終監視系統（操作系統和硬件），而不僅僅是JVM。
您必須記住，Java不使用/遵循其自己的線程模型。 此外，當前的JVM（熱點）使用本機OS線程，并且線程調度由底層OS實現。
參考：處于Java集成和源博客的優點的 JCG合作伙伴 Adrianos Dadis并沒有真正運行處于RUNNABLE狀態的Java Thread 。
翻譯自: https://www.javacodegeeks.com/2012/08/java-thread-at-runnable-state-is-not.html
![android 360加固 例子,[原創]利用VirtualApp實現360加固的soHook簡單例子](http://pic.xiahunao.cn/android 360加固 例子,[原創]利用VirtualApp實現360加固的soHook簡單例子)
獲取為NAN的問題)
