首先事情的起因是寫了一個查詢列表的功能，自測沒問題，上到測試環境也沒事，但是過兩天測試人員說報錯了，必現的錯誤，我去看日子，發現是系統堆內存溢出了，然後呢，我就主要檢查代碼有沒有遞歸循環呀，有沒有過多地循環調用呀，進行了一些優化，然後就不報錯了。可是呢，過兩天又報錯啦，還是OutOfMemoryError: Java heap space，堆溢出啦。然後就開始檢查了。
首先在日子中發現了問題，代碼在進行查詢後將list結果進行整理，最後return前會打印日誌顯示list的數量，發現日誌打印出了list的數量，說明拉取代碼沒有問題，是在返回的時候報錯了。然後又仔細看日誌，發現了一個類，是系統中的，進去後看，原來是響應結果加密的類，在加密過程中，使用了logger.info()將全量的list結果進行日誌輸出了，啊呀，很可能就是日誌量過大，導致系統堆溢出。然後我就在研發環境想復現錯誤。
之前在測試環境，響應list中數量是55的時候就報錯了。來到研發環境，響應結果list的數量是60，發現沒問題=。=，啊呀，什麼鬼啊。然後呢，我就去看看服務器的內存信息，發現研發環境剩餘內存1200M，測試環境剩餘內存500M，難道是這個原因嗎？就是測試環境服務器的剩餘內存過小，日誌輸出的時候，由於日誌量大，導致了系統堆溢出嗎？然後我就聯繫測試人員，我吧代碼中日誌輸出的那一行註釋了，讓測試人員重啓了測試環境。
測試環境重啓後，發現系統不報錯了。現在大致問題可以定位是由於測試服務器的剩餘內存本就不多，日誌輸出量達到一定量的情況下，會導致堆內存溢出。
所以呢，我覺得就是日誌輸出的話，最好就是需要哪些信息就輸出哪些，最好不要全量輸出，不然查看日誌的時候，滿屏的刷啊刷，都不是我想看到了。
我在網上也查看了關於日誌輸出會不會導致內存溢出，發現也有人遇到這種情況，日誌輸出也是耗內存的。
最後呢，對於java內存呀，堆內存呀，還是需要多去了解了解，探究細緻一點，便於日後工作呀。