Log4j-1.2.8配置项梳理

7月份帮国内一个项目现场诊断java coredump的问题，发现内存中大量的log4j日志信息，为解决问题就按照代码调用的处理流程梳理了一遍log4j-1.2.8的代码，今天把未完成的部分继续梳理了下，形成下图。

[img]http://dl2.iteye.com/upload/attachment/0122/2246/83ac0411-300d-3aef-b346-78733aca310e.png[/img]

一并整理出了log4j的配置项目(v1.2.8)

#log4j-1.2.8配置文件样例
#log4j.configDebug已经被log4j.debug所取代.表示是否启用针对log4j本身的调试日志(LogLog工具类),默认false
log4j.debug=true/false

#设置日志阈值 在进行日志输出时(如log.info(Object))时，会用INFO与threshold做比较,不低于threshold的才会被处理,默认是最低的ALL
#FATAL = 50000/ERROR = 40000/WARN  = 30000/INFO  = 20000/DEBUG = 10000
log4j.threshold=DEBUG/INFO/ERROR/...  

#设置loggerFactory的类,默认org.apache.log4j.DefaultCategoryFactory
log4j.loggerFactory=factoryClassName

#注入到LoggerFactory对象的属性
log4j.factory.xxx=yyy

#log4j.rootCategory与之相同效果.设置root的level和需要输出到的appender
log4j.rootLogger=DEBUG/INFO/ERROR,appenderName,appenderName

#log4j.logger.与之效果相同.设置loggerName的level和需要输出到的appender
log4j.category.loggerName=DEBUG/INFO/ERROR,appenderName,appenderName

#当Hierarchy是org.apache.log4j.RendererSupport实现类时，该设置才有效。默认的org.apache.log4j.Hierarchy已经实现了org.apache.log4j.RendererSupport
#renderedClass:info(Object)方法中Object参数的对象类型,renderingClass:用于对info(Object)对象进行渲染的具体处理类
log4j.renderer.renderedClass=renderingClass

#默认true,设置logger的additivity,如果additive=false,表示callAppenders时到此为止，不再往上遍历parent
log4j.additivity.loggerName=true/false

#Appender的配置
#设置appenderName对应的Appender实现类
log4j.appender.appenderName=org.apache.log4j.DailyRollingFileAppender

#设置注入到Appender中的属性(当appender是org.apache.log4j.spi.OptionHandler子类时),如file=xxx, maxfilesize=xxx.具体属性清单看DailyRollingFileAppender等类
log4j.appender.appenderName.xxx=yyy

#设置appender对应个日志格式布局类
log4j.appender.appenderName.layout=org.apache.log4j.PatternLayout #Appender日志格式布局

#设置注入到layout中的属性,如ConversionPattern=[%d] [%t] (%F:%L) %-5p %c - %m%n.具体属性清单看org.apache.log4j.PatternLayout等类
log4j.appender.appenderName.layout.xxx=yyy

说回这个项目，当初诊断后怀疑是BES上的某个配置使得System.io被替换为BES所提供的io,形成了环路，导致日志信息在内存中重复追加到StringBuffer中，最后导致coredump。
最后项目现场说替换了配置文件就解决了，问替换了什么配置，打死也不说。。。太没有配合精神了，至今不知如何解决的。