系統介紹：

之前線上跑著一個索引系統，該索引系統主要功能將數據庫的數據取出來構建成一個大的反向索引對象，存儲在本地cache中，然后供業務方進行查詢使用。該系統主要分為兩大模塊，一個為controller，一個為server。controller主要負責數據的更新操作，當數據更新后，廣播消息通知server并發送一個版本號newVersion（假設為newVersion=10）。server收到消息后，會獲取Redis的當前索引對應的版本號curVersion，如果newVersion>curVersion，那么則說明需要重建索引，就會先加鎖（避免多臺同時構建），然后加載數據并構建索引，再將索引對象以及最新的版本號存儲到redis，更新本地cache中的索引對象，最后釋放鎖，如果加鎖失敗（說明有其他的機器在構建索引了），則等待一段時間之后再重新獲取curVersion并newVersion比較。當newVersion<=curVersion,則直接從緩存中加載索引，更新到本地cache中

問題：

某天忽然有一臺server服務器出現了OOM異常，感覺很奇怪，通過使用jmap導出了堆信息，并通過MAT分析發現，索引上有兩個對象引用的大小是一樣的，查看代碼發現，原來在構建索引對象時，為了使用方便，將一個對象賦值給了兩個引用，這種方式，在內存中是占用一份數據的大小，不會有問題。然后序列化之后，再反序列化回來，就不是同一個對象了，在內存中就會占用兩份數據，這樣就會導致數據大小擴大了許多

改進：

找到了問題，就很好處理了，將重復的那個引用去掉，內存占用立馬少了600多M

繼續改進：

由于索引數據中的很多字符串相同的，都是城市名字，但是對象從redis中取出來是通過反序列化實現的，無法使用inter()的方法來減少內存的占用。后來在網上查到如果是G1垃圾收集器的話，可以使用-XX:+UseStringDeduplication來進行字符串排重，以下是排重后的效果圖，大概可以看出char數組由原來的429M減少到了82M多，注意UseStringDeduplication只會減少char數組的量

關于-XX:+UseStringDeduplication

在應用程序啟動期間傳遞此JVM參數時，JVM將嘗試在垃圾收集過程中消除重復的字符串。在垃圾收集過程中，JVM會檢查內存中的所有對象，因此作為該過程的一部分，它會嘗試識別它們中的重復字符串并嘗試消除它。

'-XX：+ UseStringDeduplication'消除了較長時間內存在的重復字符串，對JavaWeb應用程序進行的真實案例研究，當使用'-XX：+ UseStringDeduplication'時，該應用程序沒有顯示任何內存緩解。但是，如果您的應用程序有很多緩存，那么'-XX：+ UseStringDeduplication'可能是有價值的（因為緩存對象通常往往是長期存在的對象）

'-XX：+ UseStringDeduplication'不會消除重復的字符串對象本身。它只替換了底層的char []。對String對象進行重復數據刪除在概念上只是對value字段的重新賦值，即aString.value = anotherString.value。

?注意：改參數只支持JDK8U20之后，垃圾收集是G1

?

轉載于:https://www.cnblogs.com/hello---word/p/11067148.html

總結

以上是生活随笔為你收集整理的记录一次缓存系统的优化过程的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。