能不能让log4j跑的“更快”，对业务总体执行时间影响更小？
?
最近事情不多，翻了一下log4j的源代码，发现这个一直跟随左右的“小伙伴”设计还是很棒的，但实现上就显得非常朴素，加上年岁已高，身上补丁可真不少。
?
尤其是发现其pom.xml的这段，更感觉其“厚重”：
?
?
但能不能让log4j跑的“更快”，影响更小呢？
?
出于好奇+好玩，下面我做了一些有点“无理取闹”的尝试。
?
我们知道，日志必须根据时间序列进行FIFO的输出，想想java.util.concurrent.BlockingQueue不就是干这个的吗，于是尝试了一下。
思路是：
1、不是真正的写日志，而是把LoggingEvent put到queue里；
2、启用另一个线程去take queue里面的Event，再真正写到我们的文件里去（真正要提高性能，可定运用于生成环境中，没人在生成环境中用ConsoleAppender吧？）。
?
?
基于FileAppender编写一个自定义的Appender，我叫BlockingQueueAppender。
代码如下：
?
?
?
然后log4j.properties文件配置成这样：
?
?
?
可想而知，这种扔到queue里就收工的做法，queue的长度当然很重要，故可以设想影响“性能”的指标为queue的大小。
下面是测试数据，我拿excel简单整理如下：
?
SN FileAppender BlockingQueueAppender queue length
1 922 1109 10
2 937 1094 100
3 938 1047 1000
4 922 1031 2000
5 937 1016 4000
6 922 906 10000
7 906 735 20000
8 953 531 30000
9 938 266 40000
10 907 187 50000 ?
?
简单转化为折线图可能看的更清楚些：
很明显，10000个循环，从debug开始算（我设置log的级别为debug），刚好50000个，我直接把queue开成50000个是最快的（好像有点废话，哈哈）
?
总体感觉真有点无理取闹，但这样做确实可以确保我们包含logger的业务代码省了不少毫秒，而即便开了50000个对象的queue又怎样呢，按照每个LoggingEvent对象不超过0.5k来推算，得考虑给logging花上25M的内存。
?
?
是不是值得呢？
?
27 楼 itstarting 2011-06-13 哈哈，我向来鼓励百花争鸣的
有时候光看代码价值不大，顶多是“哦，原来这样啊”——动动手才好，尤其是自己想些歪招，取巧而已
谢谢你的临门一脚 28 楼 kimmking 2011-06-13 log4j本身的扩展设计还是不错的。 29 楼 凤凰山 2011-06-13 完全可以啊，log4j他爹就说了10个原因换log4j，用logback这个新的日志工具，这里有ppt
10 reasons to use logback !------log4j他爹告诉你为何要使用新的日志包logback
http://guosxu.iteye.com/blog/969152
30 楼 itstarting 2011-06-13 kimmking 写道log4j本身的扩展设计还是不错的。
严重同意
而且概念很简单，logger/appender/layout/...屈指可数但处处闪光
不过不看代码，还真不知道一些关键东西，比如不鼓励使用category而应使用logger，不鼓励使用PatternLayout而应使用EnhancedPatternLayout等等 31 楼 油炸大龙虾 2011-06-13 老外有个BT思路，如何保持日志连贯性并减少锁等，用的是ThreadLocal，呵呵 32 楼 isaac.198 2011-06-14 楼主的图是用什么画的呀 33 楼 itstarting 2011-06-14 isaac.198 写道楼主的图是用什么画的呀
这位兄台居然关注这个：把数据粘贴到excel，设置一下即可 34 楼 itstarting 2011-06-14 油炸大龙虾 写道老外有个BT思路，如何保持日志连贯性并减少锁等，用的是ThreadLocal，呵呵
有帮助吗？在我看来，一点都没有：
1、ThreadLocal是能避免数据在不同线程的冲突——因为压根就是井水不犯河水；
2、都要写到一个地方，比如console、file...请问这个冲突岂是启用ThreadLocal所能避免？ 35 楼 dingherry 2011-06-16 你们讲的我都听不懂，怎么办？
现在才刚刚会用SSH整合框架……
27 楼 itstarting 2011-06-13 哈哈，我向来鼓励百花争鸣的