|
该帖已经被评为良好帖
|
|
|---|---|
| 作者 | 正文 |
|
发表时间：2011-06-10
dwbin 写道 用内存换时间，想法不错，不过总觉着目前的应用没必要实时到这个地步吧？如果对于单笔业务的要求到了毫秒级别的话，我觉着业务是不是有问题啊？
一般的企业应用，确实不用太抠这个门 但互联网应用呢？国家级的大型应用呢？当然了，负载多就扩展嘛。 但无论怎么搞，单个业务执行时间总是有扩不动的时候（毕竟是有极限的），这里权当扩展思路咯 |
| 返回顶楼 | |
|
发表时间：2011-06-10
HelloJimmy 写道 非无理取闹；
我在2008年做一个项目就用到这种异步log的做法，主要的原因是：当时的系统非常庞大，业务很复杂，log的东西也非常多； 给咱分享分享？ |
| 返回顶楼 | |
|
发表时间：2011-06-10
最后修改：2011-06-10
HelloJimmy 写道 非无理取闹；
我在2008年做一个项目就用到这种异步log的做法，主要的原因是：当时的系统非常庞大，业务很复杂，log的东西也非常多； 只不过buffer一下而已。 |
| 返回顶楼 | |
|
发表时间：2011-06-10
log4j有个AsyncAppender，异步输出的，思路上都是一样的。只不过它用的ArrayList做为buffer，同步控制用了synchronized而已。
性能提升的很多思路都是一样的，要么就是减少I/O阻塞，减少锁竞争。 |
| 返回顶楼 | |
|
发表时间：2011-06-11
supben 写道
log4j 效率低在判断上。
除非你打每一种级别都加判断，如debug加上 if (logger.isDebugenabled()){ logger.debug(...); } 所以都用slf4j! 我们总监说的，希望能对楼主有所帮助
slf4j只是一个桥接器，确实减少了不必要的对象创建产生的时间。 “log4j 效率低在判断上。”意思是我们平时写代码很多时候使用了字符串+，而没有加上if (logger.isXXXenable())判断打log是不是必要，而slf4j正好做了这个事情。
HelloJimmy 写道
非无理取闹；
我在2008年做一个项目就用到这种异步log的做法，主要的原因是：当时的系统非常庞大，业务很复杂，log的东西也非常多； 这个我也觉得不是无理取闹，平时用warn问题不大，特别是调试生产系统时，需要大量的debug甚至trace日志，异步日志记录才是王道。 |
| 返回顶楼 | |
|
发表时间：2011-06-11
没用过log4j，从来都是jdk的Logger.
|
| 返回顶楼 | |
|
发表时间：2011-06-11
错，大错特错，slf4j最根本的差别不是支持桥接模式，而是支持log.debug("XXXXX{},XXX{}",a,b),像这种的模式，这样才能减少字符相加产生的碎片，知道不？如果仅仅是支持桥接模式的话，那common-log早就支持桥接模式了。
|
| 返回顶楼 | |
|
发表时间：2011-06-11
bao231 写道 错，大错特错，slf4j最根本的差别不是支持桥接模式，而是支持log.debug("XXXXX{},XXX{}",a,b),像这种的模式，这样才能减少字符相加产生的碎片，知道不？如果仅仅是支持桥接模式的话，那common-log早就支持桥接模式了。 SLF4J - Simple Logging Facade for Java 楼上的言语激进了些，不过其核心确实是这样的，就是一个简单的facade，并能克服common-logging的一些classloader的问题 |
| 返回顶楼 | |
|
发表时间：2011-06-12
log4j的file appender有
bufferIO和 AsyncAppender模式 其实都是BlockingQueue的方式 一种缓冲的是bytes[]，一种是记录数。 因为缓冲，不用每次写磁盘（flush=true），批量写入性能更高，曲线更平滑， 因为异步，跑在独立的线程，对系统本身就影响更小。 |
| 返回顶楼 | |
|
发表时间：2011-06-12
没必要自己实现。
|
| 返回顶楼 | |
