1樓：
這個可以勝任，不必擔心，而且10g真的不算是很大的記憶體。考慮業務自然是拆成微服務更好，但是就此來說也沒問題。但是你考慮下其他的方面這樣子搞合適不合適了。
2樓：Ted Mosby
好了，我舉個我工作過的網際網路某司的伺服器應用的例子吧，例舉的資料保證數量級是正確的，就這麼個意思吧。該應用的SLA (Service Level Agreement) 是反應時間95% percentile在100ms以內。
所以，我們定的是讓Young GC 控制在30ms，CMS GC盡量推延發生，以保證應用本身有足夠的時間來做運算。正因為我們的service是要求100ms以內完成，其實就意味著新生代在Young GC 發生時其實堆滿大量的floating object，Young GC 工作量並沒有那麼大；能promoted到老生代有很大一部分都是load進來的各種cache。
2023年前G1 GC還打磨得不夠成熟，GC演算法我們選型定的是CMS GC。32核伺服器，Heap大小開的20G吧，新生代5G，其他引數根據上述要求微調了一下下。
結果就是：5s左右發生一次Young GC，停頓25ms吧，CMS GC至少要幾小時甚至一天才發生一次，滿意地完成了上述SLA 條件。
對停頓敏感，用parnew+cms，再做優化對吞吐敏感，用parallelgc+paralleloldgc，再做優化
g1 gc的話：網際網路公司生產環境實戰表明，對大heap，有很多corner case會被hit，需要expertise knowledge來調優，但是明顯能看出g1越來越穩定和優良了。
3樓：小豬
我想對大多數應用來說，32G以下的堆的gc停頓都不是什麼問題。至於32G以上的超大堆，G1也足夠成熟了。
PS. 我司的伺服器是基本16－26GB heap。
4樓：趙北雲
GC停頓時間過長是現象本質是"什麼原因導致你的物件存活時間過長"
乙個服務的瓶頸不僅僅在記憶體上網路、硬碟IO都要考慮在內如:
"Reactor模式中 Reader/Sender處理能力跟不上Handler"
"用了宣告式事務事務粒度過大(方法中包含相當多與事務無關的執行任務) 連線占用時間長導致連線池資源不夠其他執行緒用"
影響處理請求的速度處理請求的速度又會影響到物件在記憶體中駐留的時間一旦時間過長就會帶進老年代就會頻繁的觸發full gc
所以我很少關心GC表現的如何因為真正的問題不是它們
Win10商店應用（UWP）都啟動慢，佔記憶體麼，為什麼？ 最新已改善
王銀鐲 WIN7 吧 就XP富麗多了 富麗的價值就是獻身記憶體 我家的開機就佔600MB 一般佔900MB 可能是你開機自運轉的軟體太多了 掃瞄整理一下 在優化一下 win10許多功用不能用。沒有win7好用。10佔記憶體 被門夾過的核桃 這似乎是個API完成的問題。長期使用發現，許多API在收到來...
java棧記憶體溢位怎麼產生？
咖啡旅行記 intlevel 1 static void callback 要outOfMemory static ArrayList list new ArrayList static void callback 夠直觀明了了吧？大家來贊我一下。 單執行緒下，xss設定太小，或者定義太多的本地變數...
貼圖開各向異性過濾會增大記憶體嗎？
楊鼎超 不清楚題主用的 API 裡面的各向異性過濾是具體哪一種，但很多各向異性過濾技術都是依賴 Mipmap 演算法改進的 其中一種演算法 Texram 是 沿著主方向增加取樣點，再平均混合，如下圖所示 上左圖的 pixel 覆蓋的 texel 四邊形如上右圖所示 四邊形的短邊用於確定 Mipmap...