What is the fastest way of (not) logging?

http://www.slf4j.org/faq.html#logging_performance

logger.debug("The new entry is "+entry+".");
logger.debug("The new entry is {}.", entry);

第二种方式将比第一种方式有30%的性能提升
但是，第二种写法是怎么实现的性能提升？

引用

What is the fastest way of (not) logging?

    SLF4J supports an advanced feature called parameterized logging which can significantly boost logging performance for disabled logging statement.

    For some Logger logger, writing,

    logger.debug("Entry number: " + i + " is " + String.valueOf(entry[i]));

    incurs the cost of constructing the message parameter, that is converting both integer i and entry[i] to a String, and concatenating intermediate strings. This, regardless of whether the message will be logged or not.

    One possible way to avoid the cost of parameter construction is by surrounding the log statement with a test. Here is an example.

    if(logger.isDebugEnabled()) {
      logger.debug("Entry number: " + i + " is " + String.valueOf(entry[i]));
    }

    This way you will not incur the cost of parameter construction if debugging is disabled for logger. On the other hand, if the logger is enabled for the DEBUG level, you will incur the cost of evaluating whether the logger is enabled or not, twice: once in debugEnabled and once in debug. This is an insignificant overhead because evaluating a logger takes less than 1% of the time it takes to actually log a statement.

    Better yet, use parameterized messages

    There exists a very convenient alternative based on message formats. Assuming entry is an object, you can write:

    Object entry = new SomeObject();
    logger.debug("The entry is {}.", entry);

    After evaluating whether to log or not, and only if the decision is affirmative, will the logger implementation format the message and replace the '{}' pair with the string value of entry. In other words, this form does not incur the cost of parameter construction in case the log statement is disabled.

    The following two lines will yield the exact same output. However, the second form will outperform the first form by a factor of at least 30, in case of a disabled logging statement.

    logger.debug("The new entry is "+entry+".");
    logger.debug("The new entry is {}.", entry);

    A two argument variant is also available. For example, you can write:

    logger.debug("The new entry is {}. It replaces {}.", entry, oldEntry);

    If three or more arguments need to be passed, you can make use of the Object... variant of the printing methods. For example, you can write:

    logger.debug("Value {} was inserted between {} and {}.", newVal, below, above);

    This form incurs the hidden cost of construction of an Object[] (object array) which is usually very small. The one and two argument variants do not incur this hidden cost and exist solely for this reason (efficiency). The slf4j-api would be smaller/cleaner with only the Object... variant.

    Array type arguments, including multi-dimensional arrays, are also supported.

    SLF4J uses its own message formatting implementation which differs from that of the Java platform. This is justified by the fact that SLF4J's implementation performs about 10 times faster but at the cost of being non-standard and less flexible.

    Escaping the "{}" pair

    The "{}" pair is called the formatting anchor. It serves to designate the location where arguments need to be substituted within the message pattern.

    SLF4J only cares about the formatting anchor, that is the '{' character immediately followed by '}'. Thus, in case your message contains the '{' or the '}' character, you do not have to do anything special unless the '}' character immediately follows '}'. For example,

    logger.debug("Set {1,2} differs from {}", "3");

    which will print as "Set {1,2} differs from 3".

    You could have even written,

    logger.debug("Set {1,2} differs from {{}}", "3");

    which would have printed as "Set {1,2} differs from {3}".

    In the extremely rare case where the the "{}" pair occurs naturally within your text and you wish to disable the special meaning of the formatting anchor, then you need to escape the '{' character with '\', that is the backslash character. Only the '{' character should be escaped. There is no need to escape the '}' character. For example,

    logger.debug("Set \\{} differs from {}", "3");

    will print as "Set {} differs from 3". Note that within Java code, the backslash character needs to be written as '\\'.

    In the rare case where the "\{}" occurs naturally in the message, you can double escape the formatting anchor so that it retains its original meaning. For example,

    logger.debug("File name is C:\\\\{}.", "file.zip");

    will print as "File name is C:\file.zip".