我們最近將系統從Sun Java 5遷移到Java6服務器VM（特別是Linux 32位上的1.6.0_16）。我們注意到垃圾收集行爲已經發生了變化，從而觸發了我們的堆警告監控系統。從Java5移動到6後，GC行爲發生變化
堆使用情況的圖表表示多少「spikier」存儲器使用概要比我們用Java5中看到，與VM讓堆的使用得到運行一個大的GC之前非常高。它似乎不是應用系統本身的問題（它實際上從來沒有耗盡內存），但是當使用率峯值接近閾值時，它給監控系統偶爾出現虛假的「發熱」信號。
我們可以增加堆最大，希望穗不只是得到更大的，但我寧願找出是否有一種方法，我們可以調整這樣的JVM參數，我們得到更流暢個人資料，即使我們失去了一點表現。
我猜有可能是我們可以通過設置來實現這一一些-XX選項，但我an't看到文檔的任何這樣的事情。任何人都知道這樣的選擇？
這聽起來像你真的想擁有的東西更像是一個concurrent collection（而不是標準的大爆炸式的集合）：
併發收集器設計爲 用於偏好較短 垃圾收集暫停，並且可以 得到 應用程序運行時與垃圾收集器共享處理器資源 應用程序。
也許更重要的是，你應該確保你使用了正確的虛擬機和正確的選項，超過了特定的垃圾收集選項。例如，我在我的生活中多次絆倒了client vs. server VM問題。
併發GC大大提高了堆配置文件，你說得對，以吞吐量爲代價的低延遲確實更適合我們的應用程序。感謝您的建議，並有一個cookie。 – skaffman 2009-12-11 10:45:52
@skaffman，餅乾！ ;-) – 2009-12-11 12:10:01
你能確認使用相同的GC方案/機制嗎？你是否計算了1.6中更高的GC開銷，或者是在任何給定的持續時間內暫停時間更長？
最大和最小堆免費指令也可能有助於您的一些堆人體工程學。
-XX:MinHeapFreeRatio和-XX:MaxHeapFreeRatio
http://java.sun.com/javase/technologies/hotspot/gc/gc_tuning_6.html#generation_sizing.total_heap
這也很有趣，並涉及新的G1收藏家：http://blogs.sun.com/jonthecollector/entry/our_collectors – skaffman 2009-12-11 10:49:55