Architecture
Main Components
Log4j使用下图所示的类。
使用Log4j 2 API的应用程序将从LogManager请求具有特定名称的Logger。LogManager将定位适当的LoggerContext，然后从中获取Logger。如果必须创建Logger，它将与LoggerConfig相关联，LoggerConfig包含 a)与Logger相同的名字，b)父包的名字，或 c) root LoggerConfig。LoggerConfig对象是从配置中的Logger声明创建的。LoggerConfig与实际交付LogEvents的Appenders相关联。
Logger Hierarchy
与普通System.out.println相比，任何日志API的第一个也是最重要的优点是：能够禁用某些日志语句，同时允许其他日志语句不受阻碍地打印。这个功能假定日志空间，也就是所有可能日志语句的空间，是根据开发人员选择的一些标准进行分类的。
在Log4j 1.x 里，Logger层次结构是通过Logger之间的关系来维护的。在Log4j 2中，这种关系不再存在。相反，层次结构是在LoggerConfig对象之间的关系中维护的。
Logger和LoggerConfig是命名实体。日志记录器名称区分大小写，它们遵循分层命名规则。
LoggerContext
LoggerContext充当日志系统的锚点。但是，根据具体情况，应用程序中可能有多个活动的LoggerContexts 。有关LoggerContext的更多细节见日志分隔部分。
Configuration
每个LoggerContext都有一个活动的Configuration。Configuration包含所有Appenders、上下文范围的Filters、LoggerConfigs，并包含对StrSubstitutor的引用。在重新配置期间，将存在两个配置对象。一旦所有Logger被重定向到新的Configuration，旧的Configuration将被停止并丢弃。
Logger
如前所述，Logger是通过调用LogManager.getLogger创建的。Logger本身不执行任何直接操作。它只有一个名称，并与LoggerConfig关联。它扩展了AbstractLogger并实现了所需的方法。当配置被修改时，记录器可能与不同的LoggerConfig关联，从而导致它们的行为被修改。
Retrieving Loggers
由于以Logger所属类的名称命名Logger是一种非常常见的习惯用法，因此提供了方便的方法LogManager.getLogger()来自动使用调用类的完全限定类名作为Logger名称。
LoggerConfig
LoggerConfig对象是在日志配置中声明Logger时创建的。LoggerConfig包含一组Filters，LogEvent在传递给任何Appenders之前，必须通过这些Filters。它包含用于处理事件的Appenders的引用。
Log Levels
Log4j 1.x和Logback都有“级别继承”的概念。在Log4j 2中，Logger和LoggerConfigs是两个不同的对象，因此这个概念的实现是不同的。每个Logger引用适当的LoggerConfig，而LoggerConfig又可以引用它的父类，从而达到相同的效果。（PS. 言下之意，概念没有变，只不过实现方式有点不一样罢了）
与Logback不同的是，在ERROR和OFF中间添加了FATAL级别。
Filter
除了根据日志级别自动过滤,如前一节所述,Log4j提供Filters,可以应用在控制传递给任何LoggerConfig之前,控制传递给LoggerConfig后但在调用任何Appenders之前,控制传递给LoggerConfig后但在调用一个特定的Appender之前,以及每一个Appender之中。以一种与防火墙过滤器非常相似的方式，每个过滤器可以返回三个结果之一，Accept, Deny或者Neutral。
虽然事件可能被Filter接受，但事件仍然可能没有被记录。当事件被pre-LoggerConfig Filter接受，但随后被LoggerConfig Filter拒绝或被所有appender拒绝时，就会发生这种情况。
Appender
appender可加性的内容仍然可以参考Logback的。
Layout
类似Logback
StrSubstitutor and StrLookup
StrSubstitutor类和StrLookup接口是从Apache Commons Lang中借来的，然后进行了修改，以支持评估LogEvents。此外，Interpolator类是从Apache Commons Configuration中借来的，以允许StrSubstitutor计算来自多个StrLookups的变量。它也被修改以支持评估LogEvents。它们一起提供了一种机制，允许配置引用来自系统属性、配置文件、ThreadContext映射、LogEvent中的StructuredData的变量。变量可以在处理配置时解析，也可以在处理每个事件时解析(如果组件能够处理的话)。有关更多信息，请参见Lookups 。