最近在研究logBack,发现logBack有许多性能可以提升的地方,欢迎大家探讨一下
最近在研究logBack,发现logBack有好多性能可以提升的地方,欢迎大家探讨一下
话说logBack是log4j升华的产物,应该性能提高不少,而且logback也得益于jdk1.5 的J·U·C提供的大量工具锁，经过实践证明，在大并发的时候ReentrantLock性能明显优于jdk原来的内部锁synchronized。
最近在做一个项目，使用到logBack作为日志记录，由于生产的时候需要开启trace级别的日志，而此生产环境要求并发效率挺高。
如果采用以前传统的线程内记录日志的话，就有可能导致日志消耗比较多资源。
目前研究logBack提供AsynAppender，发现此AsynAppender用了个BlockingQueue，但是不知道为什么用ArrayBlockingQueue，不用LinkedBlockingQueue，在大并发的时候，此queue有明显的优势。
因为AsynAppender不能单独使用，需要另挂一个Appender，比如RollingFileAppender。这个Appender继承了OutputStreamFileAppender，OutputStreamFileAppender只是把BufferedOutPutStream包装一下，加入一些layout以及一些格式方面的东西。但是OutputStreamFileAppender在同步方面使用大量synchronized，由于AsynAppender已经做了，同步了，再次同步已经没必要了，而且synchronized的性能又不那么好，看来有优化的余地。
另外LayoutWrappingEncoder是配合OutputStreamFileAppender一起使用的，里面有个ImmediateFlush的开关，可以延迟写io，但是什么写io呢，取决于bufferedOutputStream的时机。
所以这里可以通过一个后台线程在不忙的时候flush积极一些
话说logBack是log4j升华的产物,应该性能提高不少,而且logback也得益于jdk1.5 的J·U·C提供的大量工具锁，经过实践证明，在大并发的时候ReentrantLock性能明显优于jdk原来的内部锁synchronized。
最近在做一个项目，使用到logBack作为日志记录，由于生产的时候需要开启trace级别的日志，而此生产环境要求并发效率挺高。
如果采用以前传统的线程内记录日志的话，就有可能导致日志消耗比较多资源。
目前研究logBack提供AsynAppender，发现此AsynAppender用了个BlockingQueue，但是不知道为什么用ArrayBlockingQueue，不用LinkedBlockingQueue，在大并发的时候，此queue有明显的优势。
因为AsynAppender不能单独使用，需要另挂一个Appender，比如RollingFileAppender。这个Appender继承了OutputStreamFileAppender，OutputStreamFileAppender只是把BufferedOutPutStream包装一下，加入一些layout以及一些格式方面的东西。但是OutputStreamFileAppender在同步方面使用大量synchronized，由于AsynAppender已经做了，同步了，再次同步已经没必要了，而且synchronized的性能又不那么好，看来有优化的余地。
另外LayoutWrappingEncoder是配合OutputStreamFileAppender一起使用的，里面有个ImmediateFlush的开关，可以延迟写io，但是什么写io呢，取决于bufferedOutputStream的时机。
所以这里可以通过一个后台线程在不忙的时候flush积极一些