Правила освобождения объектов Kotlin

kotlin

Статья о необ­ходимос­ти осво­бож­дения объ­ектов в опре­делен­ных ситу­ациях.

Од­на из важ­ней­ших осо­бен­ностей Java и Kotlin — авто­мати­чес­кое управле­ние памятью, ког­да сбор­щик мусора сам уда­ляет неис­поль­зуемые объ­екты из опе­ратив­ной памяти. Сбор­щик мусора сущес­твен­но упро­щает жизнь раз­работ­чикам, но он не всег­да работа­ет.

РЕКОМЕНДУЕМ:

Ка­нони­чес­кий при­мер, ког­да сбор­щик мусора не справ­ляет­ся, — это активнос­ти Android. Рас­смот­рим сле­дующий при­мер:

Раз­работ­чик решил упростить себе жизнь и вынес фун­кцию logError в companion object, что­бы всег­да иметь к ней дос­туп. Проб­лема здесь толь­ко в том, что logError внут­ри себя ссы­лает­ся на на MainActivity. В ито­ге, если MainActivity будет завер­шена, она про­дол­жит занимать память — сбор­щик мусора не смо­жет ее осво­бодить по при­чине сущес­тво­вания ссыл­ки на активность в объ­екте‑ком­пань­оне.

Ре­шить эту проб­лему мож­но, заменив жес­ткую ссыл­ку на WeakReference (хотя по‑хороше­му проб­лема реша­ется с помощью сис­темы внед­рения зависи­мос­тей).

Еще один при­мер — реали­зация сте­ка:

Она абсо­лют­но кор­рек­тна, за исклю­чени­ем одно­го момен­та: фун­кция pop() не уда­ляет эле­мент из мас­сива. Это зна­чит, что если соз­дать стек из 1000 эле­мен­тов, а затем уда­лить 999 из них, стек все рав­но будет занимать память, необ­ходимую для хра­нения 1000 эле­мен­тов. Исправ­ляет­ся код вот так:

Как обна­ружить такие проб­лемы? Сто­ит научить­ся поль­зовать­ся ана­лиза­тором хипа (такой есть в стан­дар­тной пос­тавке Android Studio). Так­же поможет инс­тру­мент LeakCanary. Он авто­мати­чес­ки опо­вес­тит обо всех утеч­ках активнос­тей.

Effective Kotlin Item 50: Eliminate obsolete object references

Понравилась статья? Поделиться с друзьями:
Добавить комментарий