Есть ли какое-нибудь ограничение на длину строки String? Или я могу ее наращивать, как обычный массив, пока память не кончится?

Integer.MAX_VALUE. Массив большего размера не создать.

Ну что ж, вполне достаточно
Спасибо

Кста....... String наращивать нельзя
Если пишем

Код

String s1 = "aaa"; String s1 += "bbb";

то на самом деле происходит примерно следующее:

Код

String s1 = new String( "aaa"); StringBuffer tmpSb = new StringBuffer( s1); tmpSb.append( new String ( "bbb")); s1 = tmpSb.toString();

Порой встречается такое:

Код

String s1=.... while(.....) {    ....    s1 = s1 + ......    .... }

По умолчанию не помню сколько Java выделяет памяти... Что-то около 60-80 метров, и при таком стиле наращивания длина строки не может превысить 30-40 метров (мы не считаем что память используется не только для наших строк). Так что работаем через StringBuffer, причем желательно угадать заранее максимальную длину строки и при создании StringBuffer'а её указать.
И напоследок вопрос: зачем такие строки? Если с большими файлами работаешь - можно попытаться найти альтернативу в nio. Можно строчки поразбить и хранить их в List'е или еще как-нить.

Это сообщение отредактировал(а) Zandr - 26.2.2005, 12:08

ЗЫ

Цитата(Zandr @ 22.2.2005, 00:57)

String s1 = new String( "aaa"); StringBuffer tmpSb = new StringBuffer( s1); tmpSb.append( new String ( "bbb")); s1 = tmpSb.toString();

В Java 1.5 используется StringBuilder вместо StringBuffer.

Zandr
Спасибо за совет. Знал же, а не подумал. Учту.
Это может привести к выделению памяти под кучу строк без ее освобождения?

Domestic Cat

Цитата(Domestic @ 22.2.2005, 10:29)

В Java 1.5 используется StringBuilder вместо StringBuffer

Это аналогичный заменитель или есть качественная разница?

StringBuilder быстрее, т.к. не синхронизирован. Он используется там, где гарантированно будет работать 1 тред.

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

Конечно.

Цитата

Это может привести к выделению памяти под кучу строк без ее освобождения?

Нет, память то будет освобождаться, просто видел один раз как для JME приложения кто-то свою функцию рекомендовал для загрузки файла в кодировке win-1251. Так там в цикле к строчке прибавлялась буковка. Автор функции (а может и не автор) еще заметил, что она медленно работает... Я вот тоже подумал с чего бы это
Просто это называется memory burning, или как-то так, когда без толку создается-уничтожается много объектов, когда можно было бы обойтись одним. Кстати, если не задать StringBuffer'у достаточной начальной емкости, то получим примерно тот же эффект.

Цитата(Zandr @ 26.2.2005, 12:13)

Кстати, если не задать StringBuffer'у достаточной начальной емкости, то получим примерно тот же эффект.

Плохо. Строка формируется по записям из БД. В зависимости от настрек пользователя некоторые таблицы загружаются, некоторые нет, т.е. невозможно предугадать необходимую емкость.

Цитата(Zandr @ 26.2.2005, 12:13)

если не задать StringBuffer'у достаточной начальной емкости, то получим примерно тот же эффект

StringBuffer при расширении, удваивает буфер. Так что тут ничего особо страшного не будет. Конечно если есть возможность спрогнозировать размер лучше ей пользоваться, но если нет, то StringBuffer работает достаточно рационально.

Еще лучше организовать свою структуру на связанных контейнерах строк. Если нужно отредатктировать подстроку разбитую на два контейнера(replace например), то тогда обьеденяем оба контейнера в один. Память при таком подходе практически не засоряется и почти не хаваем лишнего.

Для выборок из БД лучше такие быстрые структуры как HAT.

Цитата(Sardar @ 27.2.2005, 00:46)

Для выборок из БД лучше такие быстрые структуры как HAT

Что такое НАТ?
У меня выборка происходит не напрямую, а через объект.

HAT структура очень простая и главная её задача эффективно увеличиватся в размерах. Естественно есть куча ограничений, потому и смотрим что конкретно нужно. Обычно выборка из БД это забивание контейнера даными и потом уже обработка. Если запрос не сортирующий и не групирующий, то можно использовать простые быстрые связанные списки, иначе разного рода деревья, позволяющие после набивки без дополнительных усилий представить как надо выборку. Нагрузка на процессор и память при таком подходе минимальная.

Цитата(Lamer @ 4.2.2005, 15:41)

Или я могу ее наращивать, как обычный массив, пока память не кончится?

Для наращивания создай свою стуктуру похожую на связанный список, хранить ты будешь строки. Естественно предлагается интерфейс строки + метод normalize, который разом склеивает все строки в одну для последующей быстрой обработки, если надо. При таком подходе память продублируется в конце(что не необходимо), в момент работы лишнего мусора не будет.