Ответ 1
Лично я использую
private final Logger logger = LoggerFactory.getLogger(this.getClass());
Основным преимуществом этого я могу вырезать и вставить его в новые классы без изменения имени класса.
Что касается того, должны ли они быть статическими, см. Должны ли члены Logger класса объявляться как статические?, с сайта slf4j, в котором говорится:
Мы рекомендовали, чтобы члены регистраторов были объявлены как переменные экземпляра вместо статического. После дальнейшего анализа мы больше не рекомендуем один подход к другому.
Взято с этой страницы:
Преимущества для объявления журналов как статических
- общая и устоявшаяся идиома
- меньше накладных расходов процессора: регистраторы извлекаются и назначаются только один раз, при инициализации класса хостинга
- меньше служебных данных памяти: декларация logger будет потреблять одну ссылку на класс
Недостатки для объявления журналов как статических
- Для библиотек, разделяемых между приложениями, невозможно использовать селектор репозитория. Следует отметить, что если привязка SLF4J и базовый API поставляется с каждым приложением (не разделяемым между приложениями), то каждое приложение будет по-прежнему иметь собственную среду ведения журнала.
- не подходит для IOC
Преимущества для объявления журналов в качестве переменных экземпляра
- Можно использовать селектора репозитория даже для библиотек, совместно используемых между приложениями. Тем не менее, селектор репозитория работает только в том случае, если базовая система ведения журнала является журнальной классикой. Селектор репозитория не работает для комбинации SLF4J + log4j.
- МОК дружеский
Недостатки для объявления журналов в качестве переменных экземпляра
- Менее распространенная идиома, чем объявление регистраторов как статических переменных
- более высокие накладные расходы процессора: регистраторы извлекаются и назначаются для каждого экземпляра класса хостинга
- более высокие издержки памяти: декларация logger будет потреблять одну ссылку на экземпляр класса хостинга
Описание
Элементы статического регистратора оценивают одну ссылку на переменную для всех экземпляров класса, тогда как член журнала экземпляра будет стоить ссылку на переменную для каждого экземпляра класса. Для простых классов, созданных тысячами раз, может быть заметная разница.
Однако более поздние системы ведения журнала, например log4j или logback, поддерживают отдельный контекст журнала для каждого приложения, запущенного на сервере приложений. Таким образом, даже если на сервере развернута одна копия log4j.jar или logback-classic.jar, система ведения журнала сможет различать приложения и предлагать различные условия ведения журнала для каждого приложения.
Более конкретно, каждый раз, когда регистратор извлекается путем вызова метода LoggerFactory.getLogger(), базовая система ведения журнала возвращает экземпляр, подходящий для текущего приложения. Обратите внимание, что в том же приложении извлечение регистратора по заданному имени всегда будет возвращать тот же журнал. Для данного имени другой регистратор будет возвращен только для разных приложений.
Если логгер статичен, он будет извлекаться только один раз, когда класс хостинга будет загружен в память. Если класс хостинга используется только в одном приложении, его не так много беспокоит. Однако, если класс хостинга распределяется между несколькими приложениями, то все экземпляры совместно используемого класса будут регистрироваться в контексте приложения, которое произошло с первой загрузкой общего класса в память - вряд ли поведение, ожидаемое пользователем.
Для получения дополнительной информации см. эту страницу.