Блог

Ребята, у меня много журналов, которые печатаются в моей небольшой утилите Java, поэтому я просто подумал об этом вопросе, если важна очень большая система и эффективность, и если у нас сгенерировано много журналов (с использованием log4j), какой объект лучше для хранения строки сообщений журнала или StringBuilder.

Если ваш выбор между

 logger.Debug(string1   string2);
 

и

 logger.Debug(new StringBuilder(string1).append(string2).toString());
 

Тогда нет никакой разницы

Но если есть много проверок и конструкций, например logString = <something> , тогда лучше использовать a StringBuilder .

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

 if (logger.isDebug())
    logger.Debug(..));
 

Много циклов процессора было потрачено впустую на объединение строк и вычисление других выражений, результаты которых вскоре будут отброшены, поскольку logger настроен на более высокий уровень.

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

То есть: возможно, вы слишком много регистрируете?

Тем не менее, добавление StringBuilder будет более эффективным, чем просто добавление строки, при условии, что вы продолжаете добавлять содержимое сообщения журнала, но я был бы очень удивлен, если бы это имело какое-либо заметное значение.

Зависит. Планируете ли вы манипулировать строками, например, объединять их вместе? Если это так, StringBuilder будет лучше. Если нет, String было бы лучше.

Большинство систем ведения журнала предоставляют какой-то механизм if для вставки параметров (например. log.Debug("foo = {}", getFooValue() ). Это предпочтительный и наиболее эффективный способ.

Некоторые люди предложат использовать stringbuilder, подобный этому: stringBuilder.append(foo).append(bar).toString() , однако это не более эффективно, чем "foo" "bar" .

Сейчас я не могу найти онлайн-источник для этого, но я помню, что если вы посмотрите на байт-код этих двух фрагментов кода, он будет идентичным.

Если вас беспокоит эффективность, ваши журналы должны быть минимально необходимыми. Журналы могут оказаться серьезной нагрузкой в вашей системе, если вы слишком много регистрируете. и когда вы делаете что-то слишком большое, разница в производительности между string и StringBuffer исчезнет.

Я бы подумал, что вы могли бы передать его как строку, которую вам лучше использовать, потому что вы сохраняете вызов toString на StringBuilder .

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

Конкатинация строк может быть очень дорогой. StringBuilder позаботится о части этого. Однако гораздо лучшим подходом является использование String.format . Этот метод принимает строку шаблона и переменное количество аргументов, которые являются безопасными для null, преобразуются в строки для подстановки.