log4j2でslf4jを使用する価値はありますか
Log4j2でslf4jを使用するかどうかを決定できません。オンライン投稿に基づくと、パフォーマンスに影響するようには見えませんが、本当に必要です。
また、これらのポイントはlog4j2を優先します。
- SLF4Jは、アプリケーションに文字列のログ記録を強制します。 Log4j 2 APIは、テキストを記録する場合、CharSequenceの記録をサポートしますが、オブジェクトをそのまま記録することもできます。
- Log4j 2 APIは、Messageオブジェクトのロギング、Java 8ラムダ式、およびガベージフリーロギングのサポートを提供します（可変配列の作成を避け、CharSequenceオブジェクトのロギング時にストリングの作成を避けます）。
先に進みます：slf4jではなくlog4j2 APIにプログラムします
安全です：Log4j2 APIはslf4jなどとまったく同じ保証を提供します-
Log4j2自体がAPIと実装モジュールに分離されたため、SLF4Jを使用する価値はなくなりました。
はい、オプションを開いたままにしておくことは、優れたエンジニアリング手法です。後で別のロギング実装に変更することができます。
過去10年間ほど、アプリケーションにこのような柔軟性を構築することは、SLF4JのようなラッパーAPIを使用することを意味していました。ただし、この柔軟性は無料では得られません。このアプローチの欠点は、アプリケーションが基礎となるロギングライブラリの豊富な機能セットを使用できないことです。
Log4j2は、アプリケーションを最小公分母に制限する必要のないソリューションを提供します。
エスケープバルブ：log4j-to-slf4j
Log4j2にはlog4j-to-slf4jブリッジモジュールが含まれています。 Log4j2 APIに対してコーディングされたアプリケーションは、いつでもバッキング実装をslf4j準拠の実装に切り替えることができます。
質問で述べたように、Log4j2 APIを直接使用するとより多くの機能が提供され、slf4jのようなラッパーAPIを使用するよりも機能的でない利点があります。
- メッセージAPI
- 遅延ログのラムダ
- 文字列だけでなくオブジェクトをログに記録します
- ガベージフリー：可能な場合、可変引数または文字列の作成を避けます
- CloseableThreadContextは、項目が終了すると、MDCから項目を自動的に削除します
（詳細については、 SLF4Jでは利用できない10 Log4j2 API機能 を参照してください。）
アプリケーションは、ネイティブLog4j2コアの実装に縛られることなく、Log4j2 APIのこれらの豊富な機能を安全に使用できます。
SLF4Jは依然として安全弁であり、アプリケーションがSLF4J APIに対してコーディングする必要があるという意味ではありません。
開示：Log4j2に貢献します
更新：Log4j2 APIへのプログラミングが何らかの形で「ファサードのファサード」を導入するという混乱があるようです。 Log4j2 APIとSLF4Jの間にこの点で違いはありません。
どちらのAPIも、ネイティブ実装を使用する場合は2つの依存関係を必要とし、非ネイティブ実装を使用する場合は4つの依存関係を必要とします。 SLF4JとLog4j2 APIは、この点で同一です。例えば：
