Eugene NewЧто не так с Java String и как вы с этим боретесь?

Не то, что нет доступа к "внутренностям" String без копирования кроме как платформо/версия зависимого Unsafe

Из-за этого скорость операций преобразования Charset'а, особенно в non-heap memory (CharBuffer), при пользование стандартными интерфейсами ниже плинтуса. Весь смысл CharBuffer'а и NIO пропадает. AFAIK.

Борятся - относительно "грязными" хаками через Unsafe (версия зависимо!) или другими, меняя грязными решениями. Поиск в google рулит

Eugene Newпожирает память, создавая 100 объектов, причем почему то одновременно.
1. Про гуано-код уже сказали. Для таких вещей предназначен StringBuilder / StringBuffer
2. AFAIK "в новых версиях" замену String на StringBuilder должен производит компилятор. Т.ч. притензия как-то запоздала лет на 5-8. Под профайлером не смотрел, но в Java 1.8 эффекта быть не должно

Integer.toString(i);

Сам это вызов автоматом будет плодить String для возврата результата.

Гуано-код. Вместо toString + append, нужно сразу делать нормальный append

https://docs.oracle.com/javase/7/docs/api/java/lang/StringBuilder.html#append(long)

public StringBuilder append(long lng)
Appends the string representation of the long argument to this sequence.
The overall effect is exactly as if the argument were converted to a string by the method String.valueOf(long), and the characters of that string were then appended to this character sequence.

Parameters:
lng - a long.
Returns:
a reference to this object.

Eugene NewGarrick,

вроде того, что такой код плохой




пожирает память, создавая 100 объектов, причем почему то одновременно.

А что ВЫ удивляетесь? Что Вы вызваете, то так и работает

SourceCode

Eugene NewУдивляюсь я тому, что временные объекты не уничтожаются сразу после вычисления выражения

1. Они уничтожаются в момент сборки мусора. Благодаря этому у Java "сверх-быстрое" (по сравнению с другими языками, разница на порядки!) выделение памяти через new

2. Сборка мусора делится на Minor GC (быструю) для сборки "временных объектов" и Full GC (медленную) для сборки мусора

"Временные объекты" хранятся нет в OldGen heap, а в Eden области (young generation). При правильной настройке GC и отстутствия гуано-кода (когда временные объекты живут значительно больше, чем время между минор-сборками мусора, т.е. временные объекты становятся не временными) - проблем с производительностью быть не должно (в оптимале)

Для "старых"/"классических" GC. Для "нового" GC - G1, вроде немного не так. Но принципы те же.

Eugene NewПоэтому от данного кода с запашком ожидаешь только лишних затрат на перераспределение памяти (чем в других языках можно и пренебречь, особенно с умным компилятором - или их вообще нет,

При правильном Java коде и отсутствия гуано-кода (но где такой найдешь?) и в Java проблем с производительностью быть не должно

Eugene Newесли строки т. н. паскалевские - фиксированного размера

На дворе XXI век. Строки фиксированного размера - пережиток прошлого )))

Eugene NewВ связи со всем этим возникает несколько вопросов....

IMHO Вопросы риторические. Как оно работает (на мой взгляд AFAIK), в кратце постарался ответить выше.

Eugene New3) Есть ли практика делать для хранения строк свои классы или StringBuilder/StringBuffer (а может каких то других классов) хватает с лихвой? В чем вообще считается правильным хранить строки?

Зависит от задачи. Если Вы разрабатываете Real-Time OS/приложение для управления ядерным реактором - то это одно. Если обычное приложение - то другое
1.1. Обычно нет. Используют String.
1.2. В String'е
1.3. Иногда используют хакерские способы работы со String. Например, для сверх-высоко-производительного NIO Web сервера может не хватить скорости выполения перекодировки из одной кодовой-странцы в другую. AFAIK. Но все равно для хранения пользуются или String или StringBuilder или CharBuffer'ом. Дальше или аккуратное кодирование или хакерские способы зализания в private поля через Unsafe.
Но тут скорее проблема не String, а концепции защиты Java (которую обходят через Unsafe).
1.4. Иногда может возникнуть желания сделать свой класс-хранилище на CharSequence. Например для парсинга файлов. Что бы избавиться от лишних копирований и выделения памяти (вместо дублирования распарсенных данных, хранить только позиции в исходном файле). Но честно говоря, затраты времени на кодирование и выйгрыш по экономии памяти / времени как-то не пропорциональный.
Хотя, вроде сверх-высоко-скоростные XML-парсеры (не для Java) такой подход используют (заявленная производительность на порядки /10-50 раз/, выше чем классических XML-парсеров).

cossack5Eugene NewLeonid Kudryavtsev,

1) Почему не удаляются временные объекты сразу после вычисления выражения, в котором они задействованы? Или все-таки удаляются? Хотелось бы понять, как это работает.


JIT компилятор это умеет делать.
AFAIK нет

JIT компилятор никак в работу подсистемы выделения памяти не вмешивается. Он, потенциально. может выкидывать не нужный код (например лишние boxing/unboxing) или заменять вызовы Java-функций на inline версии на C (например toInteger() в C вариант с возвратом не String, а CharSequence, но сомневаюсь, что такой inline есть в сорцах Java).

Но не вмешиваться в распределение памяти. Если бы вмешивался, это было бы очень и крайне странно.

IMHO

Eugene NewСтранно сделали разработчики Java - вроде бы сделали тип String с семантикой значения, а не ссылки, разрешили использовать в выражениях с операторами, но корректное удаление после вычисления выражения не сделали. Хотя как раз с ТАКОЙ реализацией (копирование=всегда создание нового экземляра) это делается безболезненно. Заболел у них тогда кто-то что ли, или уволился. Или я чего то не понимаю и есть причины, по котором они это не сделали и не могут сделать до сих пор в своем основном компиляторе?
Там сделано корректное удаление. В Java, уделение через GC !

И это оправдано. Т.к. оператор new в других языках, занимает какое-то время (т.к. нужно найти free память в heap). А в Java - это практически мгновенная операция! (разница работы new в C# и Java - AFAIK порядки, в Java в десятки-сотни раз быстрее)

Но любой выйгрыш, где-то имеется подводные кани. Выигрываем на new, но теперь нужна очистка памяти в GC.

Но опять таки, об этом подумали. Heap (и GC) разделен нв область для ВРЕМЕННЫХ объектов (young-генерация) и ПОСТОЯННЫХ объектов (oldgen). Для которых используют совершенно разные алгоритмы сборки мусора. В оптимале, если во young только временные объекты, их удаление так же будет "мгновенно". Но на практике, т.к. программисты пишут гуано-код, то все работает не совсем так, как ожидалось создателями языка ))))

Плюс теоретики от ООП и новых технологий. Проблема не в распределнии памяти, а в концепции имутабельности объектов (необходимость лишнего копирования/создания иммутаблеьных объектов). Но такая же проблема будет в любом другом языке!

AFAIK