Проблема в использовании StringBuilder

Question

Я работаю над оптимизацией памяти куска кода. который отвечает за передачу файла изображения на другой компьютер. Размер файла изображения составляет 240 МБ, а текущий размер кучи приложения составляет 1536 МБ.

Текущий код

byte[] buf = new byte[size];

while ((num = is.read(buf)) > 0) {
...
String str = new String(buf, 0, num));
...
sendToPc(str);
}

Это создает много строковых объектов, и когда я пытаюсь отправить изображение на более чем 5 ПК, у него заканчивается куча. Поэтому я подумал об использовании строителя строк (меня не волнует синхронизация)

Но у строителя строк нет варианта, подобного

byte[] buf = new byte[size];
StringBuilder str = new StringBuilder(size); 
while ((num = is.read(buf)) > 0) { 
...
str.insert(0,buf); --> Apparently can not append byte array. 
...
str.delete(0, str.length());
}

И даже если я попробую str.insert(0,new String(buf, 0, num)), это ничего не изменит.

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

Привет

Дхирадж Джоши

Answer 1

Вы не должны использовать строки для хранения двоичных данных.Строки содержат символы.Когда вы вызываете конструктор String, принимающий байтовый массив в качестве аргумента, вы строите строку на основе кодировки по умолчанию платформы, которая преобразует байты в символы.Javadoc говорит:

Поведение этого конструктора, когда заданные байты недопустимы в кодировке по умолчанию, не указано

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

Почему бы вам просто не передать байты как байтовый массив?

Answer 2

Вы можете попробовать IOUtils из библиотеки apache common io .Он предоставляет методы для копирования больших файлов.По той же теме статья «Причины раздувания, границы здоровья» действительно поучительна.

Answer 3

Требуется ли отправить изображение в sendToPc в виде строки?Некоторые ByteBuffer, вероятно, будут лучше соответствовать вашим потребностям ...