約1か月前、アクティブな開発では、束に割り当てられた768MBのメモリが80％に達すると、マウスの移動、フォーカスの切り替え、マウスホイールのスクロール、ウィンドウの直接スクロールなどのアクションが大量のメモリ消費を引き起こし、残りの20％が消費されることに気付きました数秒の作業で。 もちろん、その後は快適な作業を忘れることがあり、コレクターの継続的な動作を考慮して環境をオーバーロードする必要があります。 今日、この状況はついに私を手に入れ、私は見つけることを決めました-実際に問題は何ですか？
直観的には、ほとんどすべてのマウスの動きとスクロールなどのアクションが特定のイベントを生成し、それらが処理されることを理解しましたが、これらのイベントは予期していませんでした。 シードの場合-エディターウィンドウでマウスを動かし、開いているクラス内で1000行スクロールするときのメモリ消費量の2つのスクリーンショット：
ムーブメント：
スクロール：
ピーク時のコード編集ウィンドウでの通常のスクロールは、数秒でほぼ100MBのメモリを消費します...マウスを動かすと、数十メガバイトのオブジェクトが生成されます...これに関する唯一の良い点は、これらすべてのオブジェクトが収集されることです。
当然、このような単純なアクションでまさにそのようなアイデアが生成するものは、私にとって興味深いものになりました。 それでは、実験を繰り返しましょう。
スクロールあたり150万個のオブジェクトは少し高価ですよね。 しかし、今では多かれ少なかれ、問題の所在が明らかになりました。 これは特定のクラスIntervalTreeImplおよびその内部クラスNodeCachedOffsetsです。 1）IntervalTreeImplソースをダウンロードし、NodeCachedOffsetsが作成された場所と方法、およびそれらが多数ある理由を確認します（ところで、多くの開発者にオープンソースコードを感謝します）。 2）スクロール時にコールスタックを分析します。
最初に、最初の方法で行ってから、何が起こっているのかを把握し、呼び出しスタックを分析して、最終的に結論が正しいことを確認しました...だから、誰が気にするのか- ここでソースを見つけることができます。 問題のあるコードを見て、自分で解決してみてください。
コードを分析した後、コールスタックに何を期待するかは多かれ少なかれ明確になります。実際に最も興味深い部分は次のとおりです。
そして
computeDeltaUpToRoot（）メソッドに注意してください。このメソッドはスタックの最後にあり、スタックのさまざまなブランチで頻繁に呼び出されます。 一般に、コードを持つことは表面上のエラーです。このメソッドは多くの場所で非常に頻繁に呼び出され、同時に問題のあるNodeCachedOffsetsクラスの新しいオブジェクトを常に生成します。 明らかに、問題を解決するには、これらのオブジェクトの絶え間ない作成を取り除いて、たとえば、単純に（オプションとして）大きなプリミティブに置き換えるか、編集ウィンドウを描画する方法を変更するだけです（多くのリファクタリングが必要です）。
一般的に、問題を美しく解決して解決策を示したかったのですが、...問題を解決するために最新のソースをダウンロードしたときの驚きを想像してください（git：//git.jetbrains.org/idea/community.git）このエラーはすでに修正されており、5か月前ですら...修正自体はこちらで確認できます 。 アイデアの最新バージョン（11.1.2）では、この修正がまだ存在しないのは奇妙です。 私はできるだけ早くそれを受け取りたいです...それにもかかわらず、みんなが製品の世話をすることは非常に楽しいです。