Минусы для определения регистратора нестатического

Question

Комментарии к этому ответу Как сократить стандартный шаблон ведения журнала Java? настоятельно рекомендуем не использовать регистраторы в качестве переменных-членов экземпляра. Я могу думать о двух отрицательных побочных эффектах:
1) журналы суперкласса с регистратором подкласса
2) объект не может быть сериализован (если не отмечен переходный процесс)

Но если сериализация не нужна, и регистрация с именем подкласса не является проблемой, есть ли что-то еще, чего следует избегать? Я думаю, что это сокращает стандартный код и позволяет избежать ошибок копирования и вставки при копировании определения переменных регистратора из одного класса в другой. Даже Spring Framework (который, я считаю, имеет очень хорошие стандарты кодирования) использует этот метод.

Answer 1

Если ваш регистратор является членом экземпляра, а не статическим, регистратор должен извлекаться каждый раз, когда создается новый объект. Хотя эти накладные расходы, вероятно, незначительны, но это один недостаток.

С точки зрения дизайна, регистраторы на самом деле не являются свойством объекта, поскольку обычно они представляют собой метаинформацию о вашей системе, а не деловую информацию внутри самой системы. Logger на самом деле не является частью чего-то вроде Car объекта, как Engine или Transmission. Привязка логгеров к объектам как членам (в большинстве случаев) не имеет смысла семантически больше, чем что-либо.

Answer 2

Возможно, вы захотите взглянуть на эти страницы, обсуждая тему:

• SLF4j FAQ: Должны ли члены класса Logger быть объявлены как статические?
• Commons Wiki: когда можно использовать статические ссылки на объекты журнала

Answer 3

Основное отличие от логирования суперкласса с именем подкласса, конечно, состоит в том, что у вас будет один Logger объект на члена вашего класса. В зависимости от того, сколько классов используют журналирование, это может быть огромное количество регистраторов, поэтому может возникнуть проблема с переполнением памяти.

Плюс с абстрактной точки зрения, регистратор действительно принадлежит классу и может использоваться всеми экземплярами, а не каждому экземпляру, нуждающемуся в собственной частной копии, поэтому имеет смысл объявить его статическим. Переверните ваш вопрос, какие преимущества он имеет, чтобы сделать его нестатичным? (Возможность передать getClass() в вызов getLogger() вместо передачи константы класса - это единственное, о чем я могу думать, и это такая крошечная вещь).

Answer 4

Еще один, возможно, незначительный недостаток памяти, особенно когда у вас много экземпляров, каждый со своим логгером

Answer 5

Одной из основных проблем является очистка экземпляров памяти. Даже если вы не создаете объекты класса, так как вы используете статические экземпляры регистратора, будут ссылки на эти объекты.

Также, как говорит apache, здесь хранятся ссылки, поэтому они не будут освобождены после использования.

Apache Wiki говорит так

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

Технический результат использования static очевиден: для всех экземпляров класса используется только одна ссылка на журнал. Это явно эффективно для памяти; нужна только одна ссылка (4 или 8 байт) независимо от того, сколько экземпляров создано. Он также эффективно использует процессор; поиск, необходимый для поиска экземпляра Log, выполняется только один раз, когда на класс ссылаются впервые.

Answer 6

Попробуйте отладить ошибку, когда вы видите сообщение, сгенерированное классом SuperClass, когда ошибка действительно регистрируется в классе SubClass. Я видел несколько ситуаций, когда разработчики создавали класс LoggingUtils, который генерирует сообщения, которые, как правило, дублируют вещи, которые уже встроены в структуру ведения журнала.

Единственная реальная ситуация, с которой я сталкиваюсь при использовании экземпляра общего ведения журнала, - это что-то вроде регистратора HttpClient общего доступа Apache httpclient.wire, который используется несколькими классами для регистрации содержимого запросов и ответов, отправляемых через клиент. Эта конкретная ситуация с журналированием не регистрирует информацию для фактической реализации пакета, она регистрирует информацию обо всей http "транзакции".