在高性能硬件上部署程序，目前主要有兩種方式：
- 通過64位JDK來使用大內存
- 使用若干32位虛擬機建立邏輯集羣來利用硬件資源
其中第一種方案，給Java虛擬機分配超大堆的前提是有把握把應用程序的Full GC頻率控制得足夠低，至少要不影響到用戶使用，比如一天出現一次，那麼就可以在深夜執行定時任務的當時觸發Full GC(關於手動觸發Full GC方式 jmap -histo:live <LVMID>)甚至可以重啓服務來保持內存空間可以維持在一個穩定的水平。
控制Full GC頻率的關鍵是看應用中絕大多數對象能否符合“朝生夕滅”的原則，即大多數對象的生存時間不應太長，尤其是不能有成批的、長時間的大對象產生，這樣老年代空間才能穩定，Full GC的平率降低。
大多數網站形式的應用中裏，主要對象的生存週期都應該是請求級（request）或者頁面級，會話級（session）和全局級（application）的長生命對象相對很少。
計劃使用64位JDK來管理內存，還需要考慮如下問題：
- 內存回收導致的長時間停頓
- 現階段，64位JDK的性能測試普遍低於32位的JDK
- 需要保證程序足夠穩定，因爲這種應用要是產生堆溢出幾乎就無法產生堆轉儲快照（因爲佔用存儲太大），即便產生也無法分析
- 相同程序在64位JDK消耗的內存一般比32位JDK大，這是由於指針膨脹（在32位虛擬機中，本地指針佔用4字節，在64位虛擬機中本地指針佔用8字節），以及數據類型對齊補白等因素導致的。