PHDファイルをEclipse Memory Analyzerで解析する
ちょっと前に業務でOOMの原因調査をした際にPortable Heap Dump (PHD) filesを解析する方法がわからなかったので備忘として残します。
ヒープダンプってどうやって出力されるのか？
OOMが発生した場合やjmapコマンドを利用すると、ヒープダンプ(メモリの中身)がファイルで出力されます。(出力される形式はhprofという形式)
jmapコマンド
プロセス、コア・ファイル、またはリモート・デバッグ・サーバーの、共用オブジェクト・メモリー・マップまたはヒープ・メモリーの詳細を出力します。このコマンドは試験的なものであり、サポート対象外になっています。
ヒープダンプを見るためのツール
ヒープダンプを解析できるツール「Eclipse Memory Analyzer（mat）」 をEclipseFoundationが作成しています。
EclipseFoundationが作成しているので、Eclipseプラグインとしても利用できるし、スタンドアローン版もあります。
ヒープダンプの解析はかなりメモリを消費するので、スタンドアローン版がおすすめです。
(ダウンロードURL)
Eclipse Memory Analyzer（mat）
PHDファイルって何?
IBMの製品のサーバー(WebSphere)を利用していると、hprof以外のファイル形式( Portable Heap Dump (PHD) files)で出力されます。
このファイルは「Eclipse Memory Analyzer（mat）」ではデフォルトでは解析できず、 解析にはDiagnostic Tool Framework for Java (DTFJ)をmatにインストールが必要です。
(参考にしたURL)
https://wiki.eclipse.org/MemoryAnalyzer
(インストール手順)
https://wiki.eclipse.org/MemoryAnalyzer#System_Dumps_and_Heap_Dumps_from_IBM_Virtual_Machines
なぜ人はコピペでプログラミングしてしまうのか
新人のソースコードレビューをしていて、コピペしてコードを書いているなというケースがたびたびあったので、コピペしたソースの問題点とどうやったら改善できるのかについて自分の意見をまとめます。
コピペでコードを作成する問題点
コピペでコードを書くことの何が問題なのか、いろいろ人によって意見があるとは思いますが
僕の中では下記の3点が特に問題だと思っています。
- 似たような処理を行うメソッドやクラスが量産され、可読性が下がる
- コピー元に不具合があった場合に不具合ごと輸入されてしまう(保守性の低下)
- メソッドやクラスが再利用されないので、仕様変更に弱い(将来の生産性が下がる)
なぜ人はコピペでプログラミングしてしまうのか
実際にコピペのコードのプルリクを出してきた新人にヒアリングした内容を踏まえて、自分ではコピペでコードを書いてしまう動機は下記のようなものかなと思っています。
- 一から考えて実装すると時間がかかる
- (特にレガシーなシステムで)既存システムで動作しているコードなので、動きが担保されており安心。
- 既存システムのコードと同様の内容なので、問題があっても言いわけがしやすい。(本質的には言い訳にもならないですが、「あそこも同じコードで動いているので。。。」などよく聞きます)
- 既存のメソッド/クラスが簡単に利用できない実装になっている(元のメソッドが再利用性を考慮していない)
改善に向けて
正直、銀の弾丸はないと思っています。
ただ何もしないと保守性の悪いコードが量産されるだけなので、下記のような対策を進めています。
-
コードの内容をプルリクを出した人に実装した内容を説明してもらう
- コードレビュー時にコピペの必要性を問う(メソッドの再利用では実現できないのか、より良い実装方法はないのかなど)
- 無理な実装期間で実装させない(しばしば厳しい期限を理由にコードの品質が下げられるので)
- チームとしてメソッドの再利用をしやすいようにリファクタリングの計画を立てる(直接的にお金にならないのでなかなか説得は難しいですが。。。)
まとめ
チームのリテラシが高い場合や新規プロジェクトではそもそもこのような問題は発生しないとは思いますが、レガシーなシステムや新人ばかりのチームだとコピペのコードが散見されます。
ただコピペのコードが増えてくると不具合の修正や機能追加のコストが少しずつ上がっていっていって手をつけられなくなりがちなので、どうにかしたい。。。
