Какие накладные расходы на создание логгеров SLF4J в статических или нестатических контекстах?
Я всегда использовал следующий шаблон для создания (SLF4J) регистраторов:
private static final Logger log = LoggerFactory.getLogger(MyClass.class);
Это сработало до сих пор, но в какой-то момент меня интересовало контекст static и необходимость проходить в конкретном литерале класса все время вместо того, чтобы просто использовать нестатический регистратор, например
private final Logger log = LoggerFactory.getLogger(getClass());
Об этом в основном спрашивали (и отвечали) перед этим для LOG4J
Должен ли журнал быть приватным статическим или нет
и здесь
Должен ли журнал всегда конечным и статическим?
Я понимаю, что final в основном является обязательным, поэтому мне остается недоумевать, насколько высоки накладные расходы на использование SLF4J в нестационарном контексте.
В:
Есть ли существенные практические служебные данные при использовании
private final Logger log = LoggerFactory.getLogger(getClass());
над
private static final Logger log = LoggerFactory.getLogger(MyClass.class);
в среднем (веб-приложении)? (нет необходимости "обсуждать" высокопроизводительные веб-приложения с большой нагрузкой)
Примечание. В конечном итоге я планирую использовать еще более приятный подход, используя CDI для получения регистратора SLF4J, например
@Inject private final Logger log;
как описано здесь http://www.seamframework.org/Weld/PortableExtensionsPackage#H-TtLoggerttInjection, но мне нужно сначала узнать о кэшировании регистратора.
Суб-вопрос: можно ли даже использовать?:
@Inject private static final Logger log;
(только начиная с CDI, если честно)
Ответы
Ответ 1
Накладные расходы для нестатических переменных (экземпляров) регистратора должны быть незначительными, если не существует много, скажем, 10000 или более экземпляров. Ключевое слово здесь ничтожно. Если создается много объектов ( > 10000), воздействие, вероятно, будет измеримым, но все равно будет низким.
В частности, регистратор экземпляра увеличивает объем памяти по одной ссылке (64 бита) на экземпляр объекта. На стороне процессора стоимость одного хэш-поиска на один экземпляр, т.е. Стоимость поиска соответствующего регистратора в хэш-таблице (малая). Опять же, обе затраты должны быть незначительными, если не создано много многих объектов.
Этот вопрос также обсуждается в часто задаваемых вопросах SLF4J.
Ответ 2
Я не уверен насчет точных накладных расходов при использовании LoggerFactory, но я сомневаюсь, что это повлияет на производительность вашего приложения. Поэтому просто используйте статические или нестатические по своему усмотрению.
Каким должно быть преимущество использования @Inject. LoggerFactory уже обеспечивает и абстрагируется от конкретного имплантата. В любом случае это будет намного медленнее, чем LoggerFactory.
Синтаксис более краткий, когда вы используете @Inject, который является истинным. Но представьте, что вы используете класс в тесте. Затем вам нужно настроить инъекцию, чтобы получить регистрацию. С обычным LoggerFactory он также хорошо работает в тестах. Если у java был общий механизм для @Inject, он работал бы отлично, но поскольку это сложнее, настройка сложнее.
