序

首先來源是 老大code Review的時候 說到日志，讓我從 log.debug 加上一個if 判斷，log.isDebug ，這一聽就想到是 為了防止debug 日志不打印，導致的String拼接等 沒必要的損耗

嗯嗯 老大說的確實有道理，改吧

我靠，這一查幾百個 log 需要加，這一個一個改也太累了

總 需求列表

• log 自動加上if判斷 如果外面有if判斷了，忽略
• 最后 寫了個idea 插件。。。。

log 自動加上if判斷 調研

剛上來，我先百度下 是不是有現成的，我現在用的lombok，按道理應該有一個屬性 控制 是否加if的，嗯嗯 沒錯，找找，我一般先看看 @Sl4J 給我提供了什么參數配置

@Retention( RetentionPolicy . SOURCE )
@Target({ElementType.TYPE})
public @interface Slf4j{
    String topic() default
    }

思考 這個topic干什么的??？

說實話 我之前沒有用過這個屬性。。。。狗頭。。

@Slf4j 注解有個topic 屬性可以進行設置要采用的logger，
topic 的值對應的就是logback.xml中定的logger name。root logger是默認就存在的。

到這 你可能要問了，root logger 是默認實現，你說是默認實現就是默認實現了？ 證據呢？

對應的啟動Config類為 ch.qos.logback.classic.BasicConfigurator

嗯嗯 根上是ROOT

有一個細節(jié)，我們在配置logback.xml的時候 都會寫這種

<logger name="com" level="DEBUG" >
    <appender-ref ref="STDOUT"/>
</logger>
<logger name="com.example.demo" level="warn" >
    <appender-ref ref="STDOUT"/>
</logger>

你是不是好奇 這種的name怎么解析的？

他是從頭開始 遍歷包名 從loggerCache 中看看是否有匹配的，一層層找

思考

不說這些理論了，一句話 按照上面配置 logback.xml 在 com.example.demo.controller 下的類執(zhí)行會打印log.info日志么？

@RestController
@RequestMapping
@Slf4j
public class DemoController {
    @RequestMapping("/test")
    public String test(){
        log.info("sad");
        return "success";
    }
}

嗯嗯 這么一實驗 沒打印啊

有人可能問了，那把2個logger 順序反過來？ 不用試了，也不行

這一看 com.example.demo的warn生效了啊，debug/info 都沒打印出來，那為什么呢？

先看一個圖

下面就要看下 這個children 當時怎么賦值的了 其實就是從 最底下 往上找，在這里找到了 com.example.demo 的配置并且應用，是因為 logger類中

int h;
do {
    h = LoggerNameUtil.getSeparatorIndexOf(name, i);
    String childName;
    if (h == -1) {
        childName = name;
    } else {
        childName = name.substring(0, h);
    }
    i = h + 1;
    synchronized(logger) {
        childLogger = logger.getChildByName(childName);
        if (childLogger == null) {
            childLogger = logger.createChildByName(childName);
            this.loggerCache.put(childName, childLogger);
            this.incSize();
        }
    }
    logger = childLogger;
} while(h != -1);

一直找到最后，返回的就是最后/最靠近 目標類的logger 配置

小結

logger 配置不是按照pom.xml的那種優(yōu)先順序，而是包名匹配 最多的生效，如果你發(fā)現 日志打印和你想的不一樣，你可以去看下 LoggerContext 類中 loggerCache 屬性的值，檢查下

如果是一個業(yè)務系統(tǒng)，可能是一種logback.xml模板，如果你是中間件/組件，就需要對logback.xml 進行改動了，因為中間件可能是 binlog監(jiān)聽等等 大數據量的，如果按照業(yè)務系統(tǒng)那種搞法 有的日志是沒必要，根據你的業(yè)務 請自由配置

說回來 lombok 到底有沒有自動加if的插件啊

lombok @Sl4j 是沒有了，百度下吧

好吧，這也什么都沒有，官網看看，哎 也沒有，按道理應該有啊，也不難。。。

我突然在想是不是這個優(yōu)化 也不像我們想的那么有優(yōu)化效果，肯定還是有必要的

log isDebug 判斷的必要性

錯誤案例

現象描述：發(fā)現某些服務器的pv數不高，但服務器的load卻不低，高于平均水平

錯誤分析

分析過程： 通過內存監(jiān)控發(fā)現，GC的動作比較頻繁，但無法找到原因，一次PLA偶然的發(fā)現了大量如log.debug(“memberId:” + member.getMemberId())代碼

原因分析

在代碼中發(fā)現如下代碼段很多： log.debug(“memberId:” + member.getMemberId())

以上代碼執(zhí)行時，分兩步：

• 先執(zhí)行的是括號中的字符串相”+”的動作，而每次”+”運算都會導致新字符串的生成，這樣就產生了很多“中間字符串”，在極大次數被調用時，這種字符串被創(chuàng)建和銷毀的數量非常龐大，從而造成了jvm gc頻繁執(zhí)行，進而影響了性能。
• 再執(zhí)行l(wèi)og.debug()函數，在生產環(huán)境log level一般大于info，所以實際不會打印debug信息綜上所述，這些代碼在生產環(huán)境不會產生日志，但會執(zhí)行字符串”+”運算，而這些運算是無意義的，所以需要先判斷日志的優(yōu)先級，方式是log.isXXXEnabled() { log.XXX(……); }

Log Level的級別： Fatal->error->warn->info->debug，級別從高到低 一般我們生成環(huán)境的log level都是error，所以對于Error以上級別的日志，不用判斷；對于error以下級別的都要加上判斷。

總結

is 判斷還是有必要的，目前沒什么別的辦法，我在寫一個idea 插件，來一個按鈕/快捷鍵 自動添加log if判斷，正好玩玩

后續(xù)

行吧，既然說了做一個idea 插件，搞起來，周末花了幾個小時搞了一版，提交了idea 審核 ，等待審核中 起名叫java-tools 開發(fā)會用的功能 我會迭代進去，有什么是你們需要的可以評論下，我會排下優(yōu)先級 開發(fā)

簡單效果：

@Slf4j
public class A {
    public void a(){
        log.info("21") ;
    }
}

點擊 ctrl + 8 一起按 或者 右鍵

變?yōu)?/p>

@Slf4j
public class A {
    public void a(){
        if(log. isInfoEnabled()){
        log. info("21");
        }
    }
}

以上就是java log is判斷引發(fā)的一系列事件解析的詳細內容，更多關于log is判斷引發(fā)事件的資料請關注腳本之家其它相關文章！

最新評論