高同時実行サービスの最適化: 読み取り/書き込みロックによって発生するメモリリークの詳細な説明

[[414812]]

JVM 関連の例外は、最前線の開発者にとって常に頭痛の種でした。なぜなら、ビジネスコードの場合、JVM の動作は基本的にブラックボックスだからです。例外が発生した場合、直感的に問題を確認して見つけることは困難です。だからこそ、その内部ロジックを研究する必要があるのです。

この記事では、最近のオンライン JVM メモリリークの例を使用して分析します。

パート1 オンラインサーバーが警報を発令

ある日、同僚が助けを求めて私に来ました。あるシステムでは、何の警告もなく一連のアラームが発生していることが判明しました。旧世代のマシンのメモリ使用量がしきい値を超えました。

1.1 まずはパフォーマンスを見る

旧世代のメモリ使用量

7 月中旬までは、メモリ使用量は比較的正常であり、各 GC で古い世代のオブジェクトの大部分をリサイクルできたことがわかります。

月の中旬以降、旧世代のメモリが徐々に増加し、解放できなくなります。明らかに、これはオブジェクトが正常にリサイクルされていないことが原因であるはずです。

メモリリーク〜

1.2 何をすべきか

新しく立ち上げたプロジェクトでこのような問題が発生した場合、影響は比較的小さいため、コードを直接ロールバックして出血を止めることが最優先となります。

しかし、このプロジェクトは明らかに何日もオンラインになっており、その間にどれだけの要求があったかは不明です。また、最近のトラフィックの増加により問題が発生しているため、トラフィックが顧客に開放されたことを意味します。

ロールバックは不可能なので、急いで問題を特定し、オンラインで修正してください。

パート2 位置決めの問題

一般的な手順:

ダンプファイルを取得する
MATなどのツールを使用して、メモリを過剰に占有する異常なオブジェクトとその参照関係を見つける
例外オブジェクトに関連付けられたコードで起こりうる問題を分析する

ただし、ダンプされたファイルは 10G を超えて大きすぎるため、MAT は基本的に無力であり、手動で分析するために印刷することしかできません。

2.1 問題コードを見つける

jmap 結果ビュー

幸いなことに、異常な物体は非常に明白です。 Point オブジェクトと GeoDispLocal オブジェクトのインスタンスは数百万あります。まず、これら 2 つのオブジェクトがコード内でどのように使用されるかを見てみましょう。

プライベート静的最終 CacheMap<String, List<GeoDispLocal>> NEAR_DISTRICT_CACHE = 新しい CacheMap<String, List<GeoDispLocal>>(3600 * 1000, 1000); 
 
プライベート静的最終 CacheMap< Integer , Point> LOCAL_POINT_CACHE = new CacheMap< Integer , Point>(3600 * 1000, 6000);

それらはすべて現在のキャッシュ CacheMap に格納されており (メモリリークの一般的な原因は、静的コレクションによって保持され、リサイクルできないことです)、ダンプファイル内の CacheMap.Entry も非常に高くなります。

CacheMap が最優先の容疑者です。まず、このキャッシュクラスがどのようなものかを見てみましょう。

パブリッククラスCacheMap<K, V> {
    プライベートファイナルロング有効期限Ms;
    プライベート LRUMap<K, CacheMap.Entry<V>> valueMap;
    //その他は省略
}

内部的には LRU 機能を備えたマップに依存します。どのように実装されますか?

パブリッククラスLRUMap<K, V>はLinkedHashMap<K, V>を拡張します。
    プライベート静的最終long serialVersionUID = 1L;
    プライベート最終int最大容量;
    // このマップは拡大しません
    プライベート静的最終フロートLOAD_FACTOR = 0.99f;
    プライベート最終ReadWriteLockロック = 新しいReentrantReadWriteLock(); 
 
パブリックLRUMap( int最大容量){
        super(maxCapacity、LOAD_FACTOR、 true );
        this.maxCapacity = 最大容量;
    } 
 
    @オーバーライド
    保護されたブール値の長男エントリを削除します(java.util.Map.Entry<K, V> 長男) {
戻る サイズ() > 最大容量;
    } 
 
    @オーバーライド
パブリックV get(オブジェクトキー) {
        試す {
            ロック。読み取りロック()。ロック();
 super.get(キー)を返します。
        ついに
            ロックを解除します。
        }
    } 
 
    @オーバーライド
公開V put(Kキー、V値) {
        試す {
            ロック。writeLock()。ロック();
 super.put(キー、値)を返します。
        ついに
            ロック。writeLock()。ロック解除();
        }
    }
    //クリアを削除
}

内部的には、LinkedHashMap を使用して実装された LRU キャッシュです。コメントによると、容量制限があり拡張性のないMAPを構築するのが目的だそうです（Baiduで調べたらネット上の実装と全く同じですね～）。では、実際の状況は本当に想像通りなのでしょうか？

2.2 LinkedHashMap によって実装された LRUMap は便利ですか?

容量と拡張に関する設定を見てみましょう。なぜ設計者は LRUMap が拡張しないと考えるのでしょうか?

 //**容量と拡張に関連するパラメータを抽出**
 //ユーザーが期待する最大容量
プライベート最終int最大容量;
 //荷重係数
プライベート静的最終フロートLOAD_FACTOR = 0.99f;
 //コンストラクタでLinkedHashMapを呼び出して初期化する
super(maxCapacity、LOAD_FACTOR、 true ); 
 
 @Override // 最も古い要素条件を削除するメソッドをオーバーライドします
保護されたブール値の長男エントリを削除します(java.util.Map.Entry<K, V> 長男) {
   //LinkedHashMap.size が制限容量より大きい場合は削除を実行します
戻る サイズ() > 最大容量;
 }

実際の使用法に応じてインスタンス化してみましょう。

maxCapacity=6000 は必要な要素の最大容量です。
load_factor=0.99 負荷係数。
マップの内部しきい値 = 8192 * 0.99 = 8110 は、次の拡張の容量サイズです。 (マップ内のテーブル容量の実際のサイズは、6000 に最も近い 2 の累乗、つまり 8192 です)。

LRU 条件関数がオーバーライドされるため、サイズが 6000 を超えると LRU 置換が実行されます。したがって、理論上、サイズが 8110 に達することはありません。

同時読み取り/書き込み競合を解決するにはどうすればよいでしょうか?

 // 読み取り/書き込みロック
プライベート最終ReadWriteLockロック = 新しいReentrantReadWriteLock(); 
  
パブリックV get(オブジェクトキー) {
   試す {
       ロック。読み取りロック()。ロック();
 super.get(キー)を返します。
   ついに
       ロックを解除します。
   }
 } 
 
公開V put(Kキー、V値) {
   試す {
      ロック。writeLock()。ロック();
 super.put(キー、値)を返します。
   ついに
      ロック。writeLock()。ロック解除();
   }
 }

同時実行時の読み取り/書き込み競合を解決するために、設計者はクエリおよび変更メソッドにロックを追加しました。パフォーマンスを考慮するために、読み取り/書き込みロックが使用されました。つまり、読み取りロックは get 中に追加され、書き込みロックは put/remove 中に追加されました。

全体的な設計により、LRUMap の固定容量と同時操作の問題がうまく解決されているように見えますが、真実は何でしょうか?

実際、この問題はずっと以前から分析されてきました[1]。これは、LinkedHashMap が読み取り/読み取り操作を実行するときに、LRU を維持するために要素を変更するため、つまり、要素をリンクリストの末尾に移動するためです。これは読み取り書き込み同時実行の問題につながりますが、この説明は漠然とした感じがするので、これに基づいて読み取り書き込み同時実行の問題をより詳しく説明することにしました。

2.3 LinkedHashMap メモリリーク解析

読み取り/書き込みロックが追加されても機能しないのはなぜですか?

ここでは、読み取り/書き込みロックの概念と適用可能なシナリオを明確にする必要があります。読み取り/書き込みロックを使用すると、複数のスレッドが読み取りロックを共有できるため、書き込みよりも読み取りが多い状況に適しています。 (読み取り操作によってストレージ構造が変更されないことが前提です)

したがって、get 操作で問題が発生します。 LinkedHashMap の get 操作は、LRU 機能を実装するために書き直されます。取得後、現在のノードはリンクリストの末尾に移動されます。

さあ、同志たち、これは明らかに書き込み操作なので、読み取りロックを追加することはまだ役に立ちますか?

つまり、複数のスレッドが入り込み、変更が行われると、どのような影響があるのでしょうか?同時実行の問題は発生しないでしょうか?

次に、ノード移動コードを比較して、マルチスレッドでの同時実行の問題を詳細に分析します。

最後に到達したらノードを移動する

実際の逆アセンブリ分析は次のとおりです。マルチスレッドの状況でメモリリークが発生する理由は次のとおりです。

タイムスライスでのマルチスレッドの取得実行

スレッド 1 が最初の 2 つのステートメントを実行した後、タイムスライスを放棄したことがわかります。スレッド 2 が p.after=null を実行すると、タイムスライスが再度放棄されました。このように、a は次の <2,B> ノードになるはずでしたが、マルチスレッドでは null になりました。最終的に、次の 2 つのノードがリンクリストから除外され、削除操作がそれらに到達できず、メモリリークが発生しました。

認証コードはここには掲載しません。ご興味がございましたら、ぜひご自身でお試しください。