Нужно ли выполнять проверку if (log.isDebugEnabled()) {...}?

Ответ 1

Заявление:

if(log.isDebugEnabled()){

Используется только по соображениям производительности. Он не является обязательным, поскольку он вызывается методом журнала внутри.

Но теперь вы спрашиваете, сделана ли эта проверка внутри, так почему я должен ее использовать? Это очень просто: если вы зарегистрируете что-то простое:

log.debug("ResultSet rs is retrieved from OracleTypes");

Тогда вам не нужно делать никаких проверок. Если вы создаете строку для записи с помощью оператора append (+) следующим образом:

log.debug("[" + System.getTimeInMillis() + "] ResultSet rs is retrieved from OracleTypes");

В этом случае вы должны проверить, включен ли журнал, или нет, потому что, если это не так, даже если журнал не выполнен, составная строка. И я должен напомнить вам, что использование оператора "+" для конкатенации строк очень неэффективно.

Ответ 2

Я знаю, что это устарело, но для тех, кто просто находит это...

Если вы используете SLF4J, вы можете избежать вызова isDebugEnabled(), используя форматирование сообщений.

Например, вместо:

Object entry = new SomeObject();
logger.debug("The entry is " + entry + ".");

Использование:

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

Форматирование сообщения не будет оцениваться, если отключено debug.

Итак, для простых случаев вы можете избежать isDebugEnabled().

Но в случае, когда построение одного из параметров может быть дорогостоящим, вы все равно захотите использовать isDebugEnabled() (даже с SLF4J).

Например:

if (logger.isDebugEnabled()) {
    logger.debug("Here is the SQL: {}", sqlWrapper.buildSQL());  // assume buildSQL() is an expensive operation
}

В этом случае вы не хотите оценивать buildSQL(), если debug не включен.

В SLF4J есть некоторые дебаты об использовании его всегда, если использовать его выборочно. Это действительно сводится к личным предпочтениям. Вы можете использовать всюду, чтобы защитить другого разработчика (неосознанно), изменив ваше сообщение журнала на что-то более сложное/дорогое в будущем.

Ответ 3

Последние версии Logger упрощают это, поэтому нет большой разницы.

Самое большое различие заключается в том, что вам не нужно создавать материал для регистрации - иногда происходит много добавления строк.

Ответ 4

Я проверил с приведенным ниже кодом, выполнив проверку моего кода и не выполнив проверку. Интересно, если проверка выполняется в нашем коде для выполнения 4-го журнала, выполненного миллион раз, для этого требуется дополнительно 400 мс. Я использую SLF4J 1.6.6. Если вы можете позволить себе потерять 400 мс на миллион запросов, вам не нужна проверка.

    long startTime = System.currentTimeMillis();
    for (int i = 0; i < 1000000; i++) {
        if (logger.isTraceEnabled()) {
            logger.trace(request.getUserID());
            logger.trace(request.getEntitlementResource().getResourceString());
            logger.trace(request.getEntitlementResource().getActionString());
            logger.trace(request.getContextMap());
        }
    }
    long endTime = System.currentTimeMillis();
    logger.fatal("With Check Enabled : " + (endTime - startTime) + " ms");

    startTime = System.currentTimeMillis();
    for (int i = 0; i < 1000000; i++) {

        logger.trace(request.getUserID());
        logger.trace(request.getEntitlementResource().getResourceString());
        logger.trace(request.getEntitlementResource().getActionString());
        logger.trace(request.getContextMap());

    }
    endTime = System.currentTimeMillis();
    logger.fatal("With Check Disabled : " + (endTime - startTime)  + " ms");

--- ВЫХОДНОЙ ---

* 2016-01-07 10: 49: 11,501 ОШИБКА [: http-bio-8080-exec-3] [com.citi.cmb.entitlement.service.EntitlementServiceImpl] [] - с проверкой включен: 661 мс

2016-01-07 10: 49: 57,141 ОШИБКА [: http-bio-8080-exec-3] [com.citi.cmb.entitlement.service.EntitlementServiceImpl] [] - с проверкой отключено: 1043 мс

Ответ 5

Причина в том, что это сделано по соображениям производительности. Если сначала проверить это, оператор log.debug(... не должен оцениваться.

Это действительно функционально то же самое.