ClassLoaderのキャッシュが昇順でチェックされているのはなぜですか？

Question

クラスローディングが降順で起こっている間に、ClassLoaderのキャッシュが昇順でチェックされるのはなぜですか？

Answer 1

JavaのClassLoaderは、委譲、可視性、一意性の3つの原則で動作します。委任原則クラスロードの要求を親クラスローダーに転送し、親クラスがクラスを見つけたりロードできなかった場合にのみクラスをロードします。可視性の原則により、子クラスローダーは親ClassLoaderによってロードされたすべてのクラスを参照できますが、親クラスローダーは子によってロードされたクラスを見ることができません。一意性の原則では、クラスを一度だけロードすることができます。これは、基本的に委譲によって実現され、子ClassLoaderがすでに親によってロードされたクラスをリロードしないようにします。言い換えれば

hereを説明した：Javaで

クラスローダはツリーに編成されています。リクエストによって、クラス ローダーは、クラスがすでにロードされているかどうかを、 が自身のキャッシュで調べます。クラスがキャッシュに存在する場合、 CLはクラスを返し、そうでなければ、要求を親に委譲します。 親が設定されていない（Nullである）か、クラスをロードできず、 がClassNotFoundExceptionをスローした場合、クラスローダーは クラス自体をロードしようとし、クラスファイルの独自のパスを検索します。クラス がロード可能な場合はそれが返され、そうでない場合はClassNotFoundException がスローされます。 キャッシュルックアップは、ツリールートに達するか、またはクラスがキャッシュ内に見つかるまで、子から の親に再帰的に行きます。 ルートに達すると、クラスローダはクラスをロードしようとし、 は親から子への再帰を展開します。

• キャッシュ
  • 親
  • 自己

このメカニズムは、クラスがに最も近いクラスローダによってロードされる傾向があることを保証：我々は 次の順序を持​​っていることをまとめますルート。

Answer 2

これは純粋に効率の問題です。キャッシュを忘れてしまった場合、クラスロードの順序では、Javaシステムクラスが常にアプリケーションクラスより優先され、クラスはチェーン内の1つのクラスローダーによってのみロードできることが保証されます。したがって、複数のキャッシュにあるクラスがないため、キャッシュを検索する順序で機能的な違いはありません。

つまり、拡張クラスローダーキャッシュとそれに続くシステムクラスローダーキャッシュを検索してから、クラスをロードしようとすると、結果がまったく同じになります。これを行うには、ロードされたクラスを検索するために余分なAPIが必要になり、キャッシュの検索が非常に迅速な操作であるため、ほとんど効果がありません。

クラスは複数のクラスローダーによってロードできますが、ローダー→親チェーン内にあるクラスではないことに注意してください。