Java 8 gives us a better solution

まえがき

通常の業務開発において、ヌルポインターは頻繁に遭遇する問題であり、

プロセスの障害や予期しない事態を招く可能性があります。

ヌルポインターを回避する必要がある理由はここにあります。では、この問題をどのように解決できるでしょうか。

ヌルポインターが発生するシナリオ

1. ラッパー型のフィールドで、自動アンボクシング時にヌルポインターが発生する。

2. オブジェクト A がオブジェクト B を含んでおり、オブジェクト A 経由でオブジェクト B のフィールドを取得する際、null チェックなしにオブジェクト B のメソッドを直接呼び出してヌルポインターが発生する。

3. 文字列比較で、null.equal("string") を実行するとヌルポインターが発生する。

4. リモートから返されるリストが空の配列ではなく null であり、そのリストに対して操作を行うとヌルポインターが発生する。

本番環境でのヌルポインター問題のトラブルシューティング方法

日々の開発では、通常ログを確認してヌルポインター問題を特定します。ログが適切に出力されていない場合は、NullPointerException がスローされた箇所からコードをトレースするしかありません。

このため、コード記述時にログ出力を組み込んでおく必要があります。

1. メソッドの呼び出し元で入力パラメーターをログ出力し、メソッドの戻り値で出力パラメーターをログ出力する。

事前にログ出力が適切に実装されていない場合は、Alibaba の Java 診断ツール Arthas を使用して対処できます。

1. Arthas を起動して JVM プロセスを取得する。

2. watch コマンドでメソッドの入力を監視する。

考察

この問題について、業務で実践してきた方法をまとめました。

最も直接的なアプローチは、null の可能性を根本から排除し、操作前に null チェックを行うことです。

プロダクト情報を例に取ってみましょう。店舗名を取得する場合、どのように書きますか。

1. 防御的チェック：すべての変数について null をチェックする。変数が null かどうかわからないたびにネストされた if ブロックを追加する必要があり、コードの階層が深くなる。

2. 早期失敗チェック：各 null チェックが終了ポイントとなり、固定文字列を返す。ただし、変数のチェックを忘れることを避けられない。

3. 手動制御：データを厳密に制御して null フィールドをなくす。ただし、すべてのデータが正常であることを保証するのは困難である。

4. Java 8 の Optional を使用して制御する。欠損値をモデル化し、変数が存在する場合はクラスを簡潔にラップする。変数が存在しない場合は、欠損値が空の Optional オブジェクトとしてモデル化される。

1. Optional でラップした ProductVO オブジェクトを作成する。

2. Optional を Optional に変換する。

3. map を使用して Optional を Optional に変換する。

4. チェーン上で任意のメソッドを呼び出し、null が返されると、結果は設定したデフォルト値になる。

上記の方法のうち、4 番目の方法は 1 行のコードでヌルポインターを排除できます。ただし、Java 8 の Optional は複数のメソッドと組み合わせて使用する必要があります。インターネット上には既に多くの詳細な解説があるため、ここでは詳しく説明しません。

flatMap と map の違いに注意する

ストリーム操作において、flatMap と map はよく使用するメソッドです。多くの人がその違いを理解していません。

map()：map は関数をリストの各要素に適用し、適用された要素のリストを返します。

flatMap()：flatMap はマッピングとフラット化を組み合わせたコンビネーターです。flatMap には、ネストされたリストを処理して結果を連結する関数が必要です。

結果が大きく異なることがわかります。

map メソッドはリストを 3 つの小さな List オブジェクトの結果セットに変換します。

flatMap メソッドは map の処理に加えてフラット化操作を行い、結果をフラットな構造に変換してすべての要素を取り出します。

この例にヌルポインターの問題はありますか。ある場合、どのように修正しますか。

まとめ

ヌルポインターの問題は大きな問題ではないように見えますが、本番環境のビジネス運用に影響を与えるため、許容できません。

この問題を解決するための明確な方針を持つ必要があります。

1. 事前：

・必ずログ出力を行い、トラブルシューティングを容易にする。

・ビジネスロジックの実装時、操作対象のオブジェクトについて不確実な場合は、必ず null チェックを行ってから操作する。

・文字列型のヌルポインターには、Objects を使用して比較する。

・必須フィールドの入力検証を行う。

2. 事中：既に問題が発生しているため、ログと Arthas ツールを通じて迅速に問題を特定し、速やかに修正してデプロイし、障害時間を短縮する。

3. 事後：コードレビューを強化して自身のコードを見直し、同様の状況の再発を防ぐ。