Flyweight: строки уже используют String pool: имеет ли смысл объединять объекты String для Flyweight?

Question

Строки уже используют шаблон проектирования Flyweight. Будет ли это полезно / эффективно для объединения общих объектов String. Как строки уже будут извлечены из пула строк?

Answer 1

Строки могут приходить из разных мест, и по умолчанию только строковые литералы находятся в пуле строк. Например, когда вы вызываете BufferedReader.readLine(), возвращаемая строка отсутствует в пуле строк.

Имеет ли смысл объединять такие строки, используя String.intern() или канонизирующую карту, зависит от того, сколько у вас дублирования, и сколько памяти вы можете сэкономить, чтобы уменьшить это дублирование.

Например, если вы читаете файл XML, может быть очень полезно канонизировать имена элементов. Если вы читаете файл данных об адресе, может быть полезно канонизировать почтовые индексы и / или названия городов. Однако в обоих случаях я бы посмотрел на использование Map вместо вызова intern(), потому что последний потребляет постоянную память (которая является более редким ресурсом, чем обычная кучная память).

Answer 2

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