Logger.isdebugenabled () Effect

It is often used in projects:
if (logger.isdebugenabled ()) {
Logger.debug ("message:" + user.getmessage ());
}
We would take it for granted that this code is intended to control the output of the log file, but by looking at the source we will find that the debug () method is the same as the isdebugenabled () method, Therefore, we can directly call the debug method where the output log is needed to achieve the purpose of controlling the output.
The following is the source code for the isdebugenabled () and Debug () methods:

public Boolean isdebugenabled () {

if (repository.isdisabled (Level.debug_int))

return false;

Return Level.DEBUG.isGreaterOrEqual (This.geteffectivelevel ());

}

public void Debug (Object message) {

if (repository.isdisabled (Level.debug_int))

Return

if (Level.DEBUG.isGreaterOrEqual (This.geteffectivelevel ())) {

Forcedlog (FQCN, level.debug, message, NULL);

}

}

So why do we have to superfluous and add such a judgment statement?

The official argument is that, for efficiency reasons, it depends on the situation.

First we look at the following code:

Log.debug ("message:" + user.getmessage ());
If our log level is info, then this statement will not be output, but this method will still be called, so the GetMessage () method will still execute. If the GetMessage () method is too complex, it takes a long time to execute. When the parameters are constructed, we enter the debug () method to determine:
if (repository.isdisabled (Level.debug_int))
Return
It's back here. This leads us to do nothing but takes time, and if the concurrency is large, the impact on performance is more pronounced.
At this time, for performance reasons, we should add isdebugenabled () to judge
if (logger.isdebugenabled ()) {

Logger.debug ("message:" + user.getmessage ());

}
But if it's such a simple output:
Logger.debug ("error");
Adding a judgment is not necessary.

Logger.isdebugenabled () Effect