加入收藏 | 设为首页 | 会员中心 | 我要投稿 李大同 (https://www.lidatong.com.cn/)- 科技、建站、经验、云计算、5G、大数据,站长网!
当前位置: 首页 > 编程开发 > Java > 正文

java – Log4J 2配置监控和按位比较

发布时间:2020-12-15 00:34:47 所属栏目:Java 来源:网络整理
导读:一位同事指出了 Log4J 2.3 code的以下片段: /** * Called to determine if the configuration has changed. */ @Override public void checkConfiguration() { final long current = System.currentTimeMillis(); if (((counter.incrementAndGet() MASK) ==
一位同事指出了 Log4J 2.3 code的以下片段:
/**
  * Called to determine if the configuration has changed.
  */
 @Override
 public void checkConfiguration() {
     final long current = System.currentTimeMillis();
     if (((counter.incrementAndGet() & MASK) == 0) && (current >= nextCheck)) {
         LOCK.lock();
         try {
             nextCheck = current + intervalSeconds;
             if (file.lastModified() > lastModified) {
                 lastModified = file.lastModified();
                 for (final ConfigurationListener listener : listeners) {
                     final Thread thread = new Thread(new ReconfigurationWorker(listener,reconfigurable));
                     thread.setDaemon(true);
                     thread.start();
                 }
             }
         } finally {
             LOCK.unlock();
         }
     }

其中counter是AtomicInteger字段,MASK设置为0x0f,nextCheck为long.

据我所知,此方法检查是否重新加载配置,但仅当计数器的值可被16整除并且下一个配置检查周期已过时才会这样做.

为什么这是按位和那里?

鉴于对于计数器实例,incrementAndGet是同步的,它可以被认为是“廉价”的限制机制吗?或者也许在“典型”nextCheck周期期间调用checkConfiguration的次数超过必要的次数,因此按位AND作为性能技巧(再次,限制?).

解决方法

是的,这是一种限制机制.在Log4j 2.3中,为每个日志事件调用此方法.按位AND表示检查的其余部分仅每16个日志事件执行一次.

正如评论中所指出的那样,在性能提升方面,这是多么有效.对System :: currentTimeMillis的调用不是免费的,并且在极端争用下AtomicLong :: incrementAndGet的性能也是degrades.

由于Log4j 2.5以上代码不再存在(见LOG4J2-89).它已被WatchManager类所取代,该类监视配置文件是否已在后台线程中修改.

(编辑:李大同)

【声明】本站内容均来自网络,其相关言论仅代表作者个人观点,不代表本站立场。若无意侵犯到您的权利,请及时与联系站长删除相关内容!

    推荐文章
      热点阅读