我有兩種類型的對象：長時間生活（緩存）和短暫生活（請求過程響應）的大規模應用。從理論上講，對於這種類型的應用程序，我認爲可以配置Young和Old空間，所以舊空間消耗是不變的，導致沒有Full GC。JVM和GC調優 - 理論沒有完整的GC
我已經更改了newSize-maxNewSize參數，但是，舊堆繼續上升直到完全GC。每次完整GC後，消耗降至20％（緩存佔用20％）。出於某種原因，我的物體進入舊空間。我有兩個犯罪嫌疑人爲什麼被移動到舊空間：
每這篇文章：http://chaoticjava.com/posts/gc-tips-and-memory-leaks/如果你有大的對象分配它告訴那些直接去舊空間。這是真的，如果是的話，是否有可以設置年輕空間的對象大小閾值的JVM Option參數？
如果我正確理解了這個過程，那麼在移動到舊節之前，對象在「從 - 從生存」部分之間切換。在移動到舊空間之前，有沒有可以設置To和From之間的切換次數的參數？
其他提示？
感謝， 阿馬爾
這聽起來像你的生存空間都不夠大。你需要使它們足夠大以至於不需要收集任何物體。一個物體只能切換進出倖存空間一次。
如果你正在分配大對象，你可以使用一個對象池來避免GC對它們的需要。您是否考慮過使用對象池來處理請求/進程/響應數據？例如一個簡單的方法就是使用ThreadLocal。
您是否嘗試過G1收集器，該收集器旨在逐步收集您的所有記憶並減少完整GC的重大打擊。
有PARAM，可以設置要與和從是多少 的開關被 移動到舊空間之前做了什麼？
是，-XX:MaxTenuringThreshold
此開關決定升職老一輩之前的「從」和「至」 Survivor空間多少次的對象跳。 Java 6和Java JDK的最大值是15。 The default value is 15 for the parallel collector and is 4 for CMS collectors。
從Sun JVM GC文檔，
使用-XX：MaxTenuringThreshold = 0跳到 立即生存年輕一代 集合 年老代的對象。
當你想要做的是相反的，如果你沒有設置這個值，這將是在默認情況下，這是相當足夠來決定對象是否確實需要進入老 - 提供正如@Peter所說，倖存者足夠大以容納這些物體。
什麼是您的SurvivorRatio設置？你的總堆是什麼？
你確定老一代的成長只是不緩存對象嗎？除非你的緩存是固定的，永遠不會改變，否則你將不斷添加到緩存中。由於已經使它到老一代的對象從緩存中過期，它們將留在內存中直到下一個完整的GC。
我已經有了更好的運氣與同步標記清掃收藏家完全消除完整的GC長時間停頓。它需要一些調整，它可以根據應用程序而有所不同。下面是我們用來運行在一秒GC暫停一個24GB的64位JVM而服務每秒100個多頁的請求與大緩存：
-Xms24g -Xmx24g -XX:+UseCompressedOops -XX:NewRatio=4 -XX:SurvivorRatio=8
-XX:+UseConcMarkSweepGC -XX:+UseParNewGC -XX:+DisableExplicitGC
-XX:+UseCMSInitiatingOccupancyOnly -XX:+CMSClassUnloadingEnabled
-XX:+CMSScavengeBeforeRemark -XX:CMSInitiatingOccupancyFraction=68
對象壽命特性發揮關鍵作用here.Important調節旋鈕是倖存者空間的大小，持久性門檻和年輕一代的規模。在策略上，我們希望物體年輕，所以如果小物品之間有足夠的空隙，很多物品會在年輕一代中死去。此外，我們可以配置持久性閾值，以便對象保留在所需數量的集合中的生存空間中。
由於我們在倖存者空間中保留大量活物並將它們從一個空間複製到另一個空間以用於多個次GC，因此增加了次GC的成本。
保持一個年輕的年輕一代自然會增加連續次要收集之間的差距，並給予更多時間去死亡。
人們可以用這些變量試驗，以減少對象的促銷活動，以老一代與上可接受的年輕一代視圖求取適當的平衡暫停
WhiteFang34我是否需要刪除此選項：-Dsun.rmi.dgc。 client.gcInterval = 3600000和-Dsun.rmi.dgc.server.gcInterval = 3600000從我的JVM參數如果我該怎麼嘗試你的params？ – Eldar 2013-08-16 05:57:03
@ Yoldar-Zi你可以保留這些RMI選項。 – WhiteFang34 2013-08-16 07:05:17