本文對使用報表過程中出現記憶體溢位問題進行簡單地分析，給出一些建議性的排查步驟和解決方法。

排查步驟與解決辦法

定位問題

首先我們要判斷出現的問題是否是由於記憶體溢位引起的，典型的後臺資訊是帶有Out Of Memory字樣，但是也不排除其他記憶體溢位的提示，如tomcat記憶體溢位可出現三種提示資訊：Java heap space、PermGen space和unable to create new native thread。而有時執行緒死鎖也會導致應用掛掉。所以我們看到具體出錯資訊如果判斷不出是何種問題，最好上網查詢確認一下。

判斷是否與報表有關

一般來說，任何應用都可能出現記憶體溢位，所以當我們確定出現了記憶體溢位，接下來要做的就是劃分區域，判斷記憶體溢位是哪部分引起的。

一般報表應用與客戶自己應用相結合的系統出現記憶體溢位的問題，需要判斷該問題是否是由報表引起的？具體方法是單獨部署報表應用並執行原操作，看是否會出現記憶體溢位。若此步驟問題重現，則按照如下步驟進行；否則，可能說明與報表無關，當然也可以按照下面的步驟繼續進行排查。

查詢問題出現的共性

一般記憶體溢位不會只出現一次，這就要求我們記錄每次出項問題的共性。如：是否訪問某張特定報表時出現？是否訪問量達到一定程度時出現？是否訪問一些大資料量報表時出現？

下面給出在如下情況下的建議設定：

3.1 訪問某個特定報表時

若我們發現，記憶體溢位每次均出現在訪問系統中某張報表時（一般後臺資訊也有體現），這時我們就需要拿這張報表看看了，主要檢視報表設計是否合理、表示式以及sql語句是否效能極其低下、報表計算是否非常複雜等。

若檢查中發現如上問題，需要做如下一步或幾步更改：

A、 理順報表設計邏輯，重新設計報表

B、 替換效能低下的表示式，如巢狀多層if時可以使用case替代

C、 更改效能低下的sql語句

D、 報表中如果做了大量的統計、排名等，儘量將其整合到sql中，即簡化報表運算

E、 使用儲存過程做資料集，並是使用order by排序（與報表展現資料順序相同）

3.2 訪問某個或某些大資料量報表時

若發現記憶體溢位均發生在訪問某個或某些大資料量報表後出現（可能需要檢視後臺資訊多次確認）。這種情況可以嘗試如下解決辦法

A、 增大jvm，即從記憶體支援上擴充。不同的應用伺服器設定方法不同，但是一定要注意並不是jvm設定越大越好，一般不超過實體記憶體的30%（建議）。

B、 配置reportConfig.xml檔案。對於資料量大的情況，潤乾提供了“資料量大的配置方案”詳見《潤乾報表在J2EE下的部署》。一般要減小maxConcurrentForReport和maxCellNum、增大cachedReportTimeout和maxWaitTimeForReport。

C、 增大實體記憶體。這個辦法可以作為終極解決方案了。

3.3 訪問量增加到一定範圍時

若訪問量達到一定程度就出現記憶體溢位的情況，可以嘗試如下解決辦法

A、 增大JVM或實體記憶體

B、 增大資料庫允許最大連線數

C、 增大應用伺服器連線池最大連線數

D、 配置reportConfig.xml檔案。對於訪問量高的情況，潤乾提供了“訪問量高的配置方案”詳見《潤乾報表在J2EE下的部署》。一般要增大maxConcurrentForReport和maxCellNum、減小cachedReportTimeout和maxWaitTimeForReport。