jugLviv

Meta


Share on:


String and memory leaks

juglvivjuglviv

String and memory leaks

Думаю всі вже знають, що String об’єкт є трішки складнішим за char масив. І для покращення роботи з стрінгами в джава поробили всякі цікаві речі, як String pool  – розроблений щоб повторно використовувати ті самі об’єкти а не створювати кожен раз нові, Інша оптимізація це додавання меж і кількість на об’єкт. Про що і піде мова далі.
Отже для чого були додані ці речі? Вони служать для того, щоб використовувати створені структури користуючись певними стандартними методами над цими структурами, як обрахування substring для заданого stringa. Принцип дії полягає в тому, що замість виділення памяті для нового обєкта використовується старий проте з цими параметрами. Оскільки операція сабстрінг є досить популярна це дозволяє зекономити досить багато памяті. Досить важливо зауважити, що це працює оскільки стрінги є іммутейбл обєктами.
Як приклад можна розглянути наступний код:

public static void sendEmail(String emailUrl) {
String email = emailUrl.substring(7); // 'mailto:' prefix has 7 letters
String userName = email.substring(0, email.indexOf("@"));
String domainName = email.substring(email.indexOf("@"));
}

public static void main(String[] args) {
sendEmail("mailto:user_name@domain_name.com");
}

Ми бачимо що створено 3 нові обєкти, проте завдяки імплементації сабстрінг в памяті виділиться тільки один character array змінної emailUrl. Що дозволяє зекономити тільки в цьому випадку практично 2/3 памяті. Ніби все файно проте як завжди є і темна сторона медалі.

public final static String START_TAG = "<title>";
public final static String END_TAG = "</title>";

public static String getPageTitle(String pageUrl) {
// retrieve the HTML with a helper function:
String htmlPage = getPageContent(pageUrl);

// parse the page content to get the title
int start = htmlPage.indexOf(START_TAG);
start = start + START_TAG.length();
int end = htmlPage.indexOf(END_TAG);
String title = htmlPage.substring(start, end);
return title;
}

В цьому випадку аналогічно замість створення обєкта для title ми повернемо цілу хтмл сторінку з зміненими count i offset. Думаю вже очевидно в чому тут недолік. Якщо ця вебсторінка не є статичним дітищем студенти 1 курсу, а якийсь таки великий об’єм даних. То замість виділення памяті на коротенький title ми будемо змушені тримати цілу вебсторінку і працювати з нею. Звісно для цього є елементарне вирішення викорситовувати return new String(title) і в такому випадку все буде гаразд.

Отже який висновок, оптимізація джавішних стрінгів річ класна і корисна проте деколи треба дивитись на потенційні проблемені місця, щоб не засмічувати память тим чим непотрібно.

http://www.javablogging.com/string-and-memory-leaks/          <-оригінал тут 

juglviv
Author