衆所周知的是熱點分析運行時的使用模式和性能特徵，然後優化基於該分析作爲Java應用程序正在運行的JIT過程。因此，在嘗試對Java應用程序進行基準測試時，通常建議小心謹慎，以便在進行實際性能測量之前允許進行分析和優化階段。部署之前的Java HotSpot分析？
我確信之前已經想到這一點，但我經常想知道爲什麼這個分析階段（例如典型的使用模式）不能以某種方式作爲構建過程的一部分完成，然後將配置數據與應用程序一起部署，以便全速JIT是在應用程序啓動時立即實現的。
有誰知道這是否是實際完成的，如果有一個原因，這是不可行的，或者如果這個正在規劃中，以增強熱點和Java應用程序的部署？
沒有「典型使用模式」的應用，尤其是在談論一個Java應用程序時。它可以在Windows，Linux，MacOS，Solaris等環境下運行。運行時環境不僅完全改變代碼的行爲，還決定運行時甚至存在哪些類。
例如，具有圖形用戶接口的應用程序將加載下Windows，Linux或不同的MacOS AWT實現類。但即使顯示器的像素格式（RGB與BGR，16位與24位）的簡單屬性也會導致應用程序採用不同的代碼路徑。並且有新的JRE版本不斷改進JFC類的代碼，從而改變運行時行爲，使任何預先計算的分析數據無用。
這是一個典型的錯誤的認爲測試和基準測試開發人員的計算機上都足以說一下真實的生產環境中任何事物。如果運行數十億併發事務，或者另一方面，客戶的PC上只有一半內存，那麼可能看起來足夠的可能會完全無法使用。
Java的優勢之一是能夠針對軟件的實際行爲和使用模式進行剖析和優化，並使用運行時發現的確切版本跨越來自不同供應商的庫的邊界進行優化。
好了，講出來的直覺，因爲它來分析，那就得更多或更少的運行代碼，或者通過它與某種邏輯的步驟。它也不能真正預測用戶輸入，最終會有一個模式。當您運行程序時，它會獲得一組很好的數據樣本 – Cruncher
是的，但總會有一些非常典型的使用模式，可以在部署之前輕鬆進行配置。爲什麼不能部署這些模式的分析信息？總是會有不太常見的使用模式，但可以像HotSpot現在在實際運行時一樣進行分析和優化。 –
什麼是「非常典型的使用模式」？如果你在程序中選擇了一個隨機的'int'變量，你能通過查看代碼來確定它是否可能低於50？ –