一、內存
JVM堆棧內存是決定應用服務器性能的關鍵指標，一般服務器默認的內存配置都比較小，在較大型的應用項目中，這點內存是不夠的，因此需要進行查看與修改Web服務器內存大小，接下來就介紹服務器內存查看的方法以及不同服務器內存的修改方式。
各應用服務器的內存配置方法不盡相同，如下列出了常用服務器的JVM參數（-Xms，-Xmx）配置方法。
JVM參數定義：
- Xms： 初始化內存大小
- Xmx： 可以使用的最大內存
以下示例工具：報表開發工具FineReport
二、服務器內存的查看
如果您想要查看應用服務器的內存配置情況，可以啟動Web服務器，進入平臺系統，URL地址為：http://localhost:8080/WebReport/ReportServer?op=fr_platform，選擇管理系統>系統監控>系統狀態>內存使用情況，即可查看到當前web服務器的內存使用情況，如下圖：
注：如果用戶購買了數據決策系統，那么URL地址可以輸入http://localhost:8075/WebReport/ReportServer?op=fs
其中:
空閑內存:204M是指可用剩余內存為：204M。
所有內存:247M是指當前調用的內存為：247M。
最大內存:494M是指可調用的最大內存為：494M。
三、FineReport內存機制
3.1 描述
在使用報表的過程中有時候會遇到內存溢出的問題，下面簡單介紹我們報表的內存機制以及怎樣釋放內存。
3.2 內存機制
3.21內存回收機制
Java的內存垃圾回收(GC)機制是從程序的主要運行對象開始檢查引用鏈，當遍歷一遍后發現沒有被引用的孤立對象就作為垃圾回收。GC為了能夠正確釋放對象，必須監控每一個對象的運行狀態。包括對象的申請、引用、被引用、賦值等，GC都需要進行監控。
在Java中，這些無用的對象都由GC負責回收，同時java提供了函數可以訪問GC, 如運行GC的函數System.gc()，但是根據Java語言規范定義，該函數不保證JVM的垃圾收集器一定會執行。因為不同的JVM實現者可能使用不同的算法管理GC。通常GC的線程的優先級別較低。JVM調用GC的策略也有很多種，有的是內存使用到達一定程度時，GC才開始工作，也有定時執行的，有的是平緩執行GC，有的是中斷式執行GC。
導致內存泄漏主要的原因是，先前申請了內存空間而忘記了釋放。如果程序中存在對無用對象的引用，那么這些對象就會駐留內存，消耗內存，因為無法讓垃圾回收器GC驗證這些對象是否不再需要。如果存在對象的引用，這個對象就被定義為"有效的活動"，同時不會被釋放。要確定對象所占內存將被回收，我們就要務必確認該對象不再會被使用。
3.22 中內存管理釋放機制說明
FineReport報表后臺采用的是純java語言編寫, 因此其內存釋放機制與上述保持一致，當客戶端與服務器端交互結束(如關閉瀏覽器頁面, 打印結束等), 服務器端會將之前客戶端操作消耗的內存釋放掉, 即置為可被回收狀態, 等候jvm調用gc
3.3中的手動GC方法
FR在1G內存下的臨界點應該在130w行*5列左右, 對于某些集成環境來說, 有可能是需要做某些操作后, 將FR占用的內存釋放掉, FR里面也提供了響應的接口, 具體使用方法如下所示:
在一個模板中添加一個按鈕, 給按鈕加上點擊事件, 或者直接在js中調用, 內容如下:
$.ajax({
url : FR.servletURL,
data : {
op : 'fr_utils',
cmd : 'gs_gc'
},
async : false,
})