RAII проти збирача сміття

Нещодавно я дивився чудову розмову Herb Sutter про "Leak Free C ++ ..." на CppCon 2016, де він розповів про використання розумних покажчиків для реалізації RAII (залучення ресурсів є ініціалізацією) - Концепції та те, як вони вирішують більшість проблем з витоками пам'яті.

Тепер мені було цікаво. Якщо я суворо дотримуюсь правил RAII, що здається непоганою справою, чому це може відрізнятися від того, що має збирач сміття в C ++? Я знаю, що з RAII програміст має повний контроль над тим, коли ресурси звільняються знову, але чи корисно це в будь-якому випадку просто мати збирач сміття? Чи справді це було б менш ефективно? Я навіть чув, що збирач сміття може бути більш ефективним, оскільки він може звільняти більші шматки пам’яті за раз, замість того, щоб звільняти невеликі фрагменти пам’яті по всьому коду.

Якщо я суворо дотримуюсь правил RAII, що здається непоганою справою, чому це може відрізнятися від того, що має збирач сміття в C ++?

Хоча обидва мають справу з розподілом, вони роблять це абсолютно різними манерами. Якщо ви звертаєтесь до GC, подібного до Java, який додає власні накладні витрати, видаляє частину детермінізму з процесу випуску ресурсу та обробляє циклічні посилання.

Ви можете впровадити GC, однак, для окремих випадків із значно різними характеристиками продуктивності. Я застосував один раз для закриття підключень сокетів на високопродуктивному / високопропускному сервері (просто виклик API закриття сокета зайняв занадто багато часу і обмежив пропускну здатність). Це стосувалося не пам'яті, а мережевих підключень і ніякої циклічної обробки залежностей.

Я знаю, що з RAII програміст має повний контроль над тим, коли ресурси звільняються знову, але чи корисно це в будь-якому випадку просто мати збирач сміття?

Цей детермінізм є особливістю, яку GC просто не дозволяє. Іноді ви хочете мати можливість знати, що через деякий момент була проведена операція очищення (видалення тимчасового файлу, закриття мережевого з'єднання тощо).

У таких випадках GC не вирізає це, що є причиною в C # (наприклад), що у вас є IDisposableінтерфейс.

Я навіть чув, що збирач сміття може бути більш ефективним, оскільки він може звільняти більші шматки пам’яті за раз, замість того, щоб звільняти невеликі фрагменти пам’яті по всьому коду.

Може бути ... залежить від реалізації.

Збір сміття вирішує певні класи ресурсних проблем, які RAII не може вирішити. В основному, це зводиться до кругових залежностей, де ви не ідентифікуєте цикл заздалегідь.

Це дає йому дві переваги. По-перше, існують певні типи проблем, які RAII не може вирішити. З мого досвіду, вони трапляються рідко.

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

Недоліком є ​​те, що без RAII важко керувати ресурсами, тривалість життя яких ви хочете обмежити. Мови GC в основному зводять вас до надзвичайно простих термінів життя, пов’язаних із сферою дії, або вимагають від вас керування ресурсами вручну, як у C, із зазначенням вручну, що ви закінчили з ресурсом. Їх життєва система об’єктів міцно пов’язана з ГХ і погано працює для жорсткого управління життєвими процесами великих складних (але без циклів) систем.

Чесно кажучи, управління ресурсами в C ++ вимагає великої роботи, щоб зробити це належним чином у таких великих складних (але без циклу) системах. Мови C # та подібні мови просто ускладнюють це, натомість вони полегшують простий випадок.

Більшість реалізацій GC також змушує не локальні повноцінні класи; Створення суміжних буферів загальних об'єктів або складання загальних об'єктів в один більший об'єкт - це не те, що більшість реалізацій GC спрощує. З іншого боку, C # дозволяє створювати значення типу structs з дещо обмеженими можливостями. У сучасну епоху архітектури центрального процесора зручність кеш-пам’яті є ключовим фактором, а відсутність локальних сил GC є важким тягарем. Оскільки ці мови здебільшого мають час виконання байт-коду, теоретично середовище JIT може переміщувати загальновживані дані разом, але найчастіше ви просто отримуєте рівномірну втрату продуктивності через часті помилки кешу порівняно з C ++.

Остання проблема GC полягає в тому, що вивільнення є невизначеним і іноді може спричинити проблеми з продуктивністю. Сучасні ГК роблять це меншою проблемою, ніж це було раніше.

Зверніть увагу, що RAII є ідіомою програмування, тоді як GC - це техніка управління пам'яттю. Отже, ми порівнюємо яблука з апельсинами.

Але ми можемо обмежити RAII його аспекти управління пам'яттю тільки і порівняйте це з методами ГХ.

Основна відмінність між так званими методами управління пам’яттю на основі RAII (що насправді означає підрахунок посилань , принаймні, коли ви враховуєте ресурси пам'яті та ігноруєте інші, такі як файли) та справжніми методами збору сміття є обробка кругових посилань (для циклічних графіків ) .

При підрахунку посилань вам потрібно кодувати спеціально для них (використовуючи слабкі посилання чи інші матеріали).

У багатьох корисних випадках (згадайте std::vector<std::map<std::string,int>>) підрахунок посилань є неявним (оскільки він може бути лише 0 або 1) і практично опускається, але функції конструктора та деструктора (суттєві для RAII) поводяться так, ніби є біт підрахунку посилань (який практично відсутня). В std::shared_ptrє справжній лічильник посилань. Але пам'ять все ще імпліцитно управляється вручну (з newі deleteзапускається всередині конструкторів і деструкторів), але ця "неявна"delete (у деструкторах) створює ілюзію автоматичного управління пам'яттю. Однак дзвінки newта deleteвсе одно трапляються (і вони коштують часу).

До речі, GC реалізація може (і часто робить) рукоятка округлість яким - то особливим чином, але залишити це навантаження на GC (наприклад , прочитати про алгоритмі Чейні ).

Деякі алгоритми GC (зокрема, генератор копіювання смітника поколінь) не турбуються вивільненням пам'яті для окремих об'єктів, це масове вивільнення після копіювання. На практиці Ocaml GC (або SBCL) може бути швидшим, ніж справжній стиль програмування C ++ RAII (для деяких , а не для всіх типів алгоритмів).

Деякі ГК забезпечують доопрацювання (здебільшого використовується для управління зовнішніми ресурсами, не пов'язаними з пам'яттю, такими як файли), але ви будете використовувати їх рідко (оскільки більшість значень споживають лише ресурси пам'яті). Недоліком є ​​те, що доопрацювання не дає жодної гарантії термінів. Практично кажучи, програма, яка використовує доопрацювання, використовує її як крайній засіб (наприклад, закриття файлів все одно має відбуватися більш-менш явно поза доопрацюванням, а також з ними).

Ви все ще можете мати витоки пам’яті з GC (а також з RAII, принаймні при неправильному використанні), наприклад, коли значення зберігається в якійсь змінній або якомусь полі, але ніколи не буде використано в майбутньому. Вони просто трапляються рідше.

Рекомендую прочитати довідник зі збору сміття .

У коді C ++, ви можете використовувати GC Boehm в або MPS Ravenbrook в або код самостійно трасування збирач сміття . Звичайно, використання ГК - це компроміс (є певні незручності, наприклад, невизначеність, відсутність гарантій термінів тощо).

Я не думаю, що RAII є найкращим способом роботи з пам’яттю у всіх випадках. У декількох випадках кодування вашої програми в справді та ефективно реалізованих GC (згадайте Ocaml або SBCL) може бути простішим (розроблятись) та швидшим (виконувати), ніж кодувати його у вишуканому стилі RAII на C ++ 17. В інших випадках це не так. YMMV.

Як приклад, якщо ви кодуєте інтерпретатор схеми в C ++ 17 із наймодернішим стилем RAII, вам все одно доведеться кодувати (або використовувати) явний GC всередині нього (оскільки купа схеми має циркулярність). І більшість перевірених помічників кодуються мовами, заснованими на GC, часто функціональними (єдиний, який я знаю, який кодується на C ++ - це Lean ) з поважних причин.

До речі, я зацікавлений знайти таку реалізацію схеми C ++ 17 (але менш зацікавлений у її кодуванні), бажано з деякими багатопотоковими можливостями.

RAII та GC вирішують проблеми в абсолютно різних напрямках. Вони абсолютно різні, незважаючи на те, що хтось сказав би.

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

Якщо ви подивитесь на останні тенденції розвитку мов, то побачите, що обидва підходи використовуються однією мовою, бо, чесно кажучи, вам дійсно потрібні обидві сторони загадки. Ви бачите багато мов, які використовують сортування сміття, тому вам не потрібно звертати увагу на більшість об’єктів, і ці мови також пропонують рішення RAII (наприклад, withоператор python ) для часу, на який ви дійсно хочете звернути увагу. їх.

• C ++ пропонує RAII через конструктори / деструктори та GC через shared_ptr(Якщо я можу аргументувати, що перерахунок та GC знаходяться в одному класі рішень, оскільки вони обидва розроблені, щоб допомогти вам не потрібно звертати увагу на тривалість життя)
• Python пропонує RAII через withта GC через систему перерахунку плюс збирач сміття
• C # пропонує RAII через IDisposableі usingта GC через генератор смітника

Візерунки з’являються на кожній мові.

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

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

Наприклад: очищення групи дрібних предметів може бути зроблено ефективніше за допомогою GC, оскільки це може звільнити великий шматок, але це буде не швидко, і важко передбачити, коли відбудеться, і через "очищення великих шматків" це буде займе трохи часу процесора і може вплинути на продуктивність програми

Грубо кажучи. Ідіома RAII може бути кращою для затримки та тремтіння . Збирач сміття може бути кращим для пропускної здатності системи .

"Ефективний" - це дуже широкий термін, у сенсі зусиль з розвитку RAII, як правило, менш ефективний, ніж GC, але з точки зору продуктивності GC, як правило, менш ефективний, ніж RAII. Однак можна навести додаткові приклади для обох випадків. Робота із загальним GC, коли у вас дуже чіткі шаблони розподілу ресурсів (де) у керованих мовах, може бути досить клопітною, як і код, що використовує RAII, може бути напрочуд неефективним, коли shared_ptrвикористовується для всього без причини.

Збір сміття та RAII підтримують одну загальну конструкцію, для якої інша насправді не підходить.

У системі зібраного сміття код може ефективно розглядати посилання на незмінні об'єкти (наприклад, рядки) як проксі для даних, що містяться в них; передавати такі посилання майже настільки ж дешево, як і навколо "німих" покажчиків, і швидше, ніж робити окрему копію даних для кожного власника або намагатися відстежити право власності на спільну копію даних. Крім того, системи зібраного сміття полегшують створення незмінних типів об’єктів, створюючи клас, який створює змінний об’єкт, заповнюючи його за бажанням та надаючи методи доступу, при цьому утримуючись від витоку посилань на все, що могло б змінити його, коли конструктор закінчує. У випадках, коли посилання на незмінні об'єкти потрібно широко копіювати, але самі об'єкти цього не роблять, GC б'є RAII вручає.

З іншого боку, RAII чудово справляється з ситуаціями, коли об’єкту потрібно придбати ексклюзивні послуги від сторонніх організацій. Хоча багато систем GC дозволяють об'єктам визначати методи "Доопрацювання" та вимагати сповіщення, коли вони виявляються занедбаними, і таким методам іноді вдається випускати сторонні служби, які більше не потрібні, вони рідко бувають досить надійними, щоб забезпечити задовільний спосіб забезпечення своєчасного випуску зовнішніх служб. Для управління незамінними зовнішніми ресурсами RAII перемагає GC.

Ключова різниця між випадками, коли GC виграє, порівняно з тими, де перемагає RAII, полягає в тому, що GC добре управляє взаємозамінною пам'яттю, яка може бути звільнена за необхідності, але погано справляється з незамінними ресурсами. RAII добре обробляє об'єкти з чітким правом власності, але погано обробляє безвласні незмінні власники даних, які не мають реальної ідентичності, крім даних, які вони містять.

Оскільки ні GC, ні RAII добре не обробляють всі сценарії, мовам було б корисно забезпечити хорошу підтримку для них обох. На жаль, мови, орієнтовані на одне, як правило, ставляться до іншого як до думки.

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

_{Крім того, ви в основному відчуваєте напругу давнього "Чи є Java або C ++ кращою мовою?" полум’яне потріскування в коментарях. Цікаво, як може виглядати "прийнятна" відповідь на це запитання, і мені цікаво її побачити.}

Але одного моменту про можливу важливу концептуальну різницю ще не вказано: з RAII ви прив'язані до нитки, яка викликає деструктор. Якщо ваша програма однопотокова (і хоча це був Герб Саттер, який заявив, що Безкоштовний обід закінчився : більшість програмних засобів сьогодні фактично все ще є однопотоковими), тоді одне ядро ​​може бути зайняте обробкою очищення об’єктів, які не є більше актуальні для фактичної програми ...

На відміну від цього, збирач сміття зазвичай працює у власному потоці або навіть у декількох потоках, і таким чином (до певної міри) відокремлений від виконання інших частин.

(Примітка: Деякі відповіді вже намагалися вказати на шаблони програм з різними характеристиками, згаданою ефективністю, продуктивністю, затримкою та пропускною здатністю, - але цей конкретний момент ще не згадувався)

RAII одноманітно має справу з усім, що можна описати як ресурс. Динамічні розподіли є одним із таких ресурсів, але вони далеко не єдиний і, можливо, не найважливіший. Файли, сокети, підключення до бази даних, зворотний зв’язок із графічним інтерфейсом та інше - все те, чим можна детерміновано керувати за допомогою RAII.

GC мають справу лише з динамічними розподілами, позбавляючи програміста від занепокоєння загальним обсягом виділених об'єктів протягом усього терміну дії програми (їм потрібно лише піклуватися про пристосування пікового паралельного обсягу розподілу)

RAII та збір сміття призначені для вирішення різних проблем.

Коли ви використовуєте RAII, ви залишаєте в стеці об'єкт, єдиною метою якого є очищення того, чим ви хочете керувати (сокети, пам'ять, файли тощо), виходячи зі сфери застосування методу. Це для винятку-безпеки , а не лише для збору сміття, саме тому ви отримуєте відповіді про закриття розеток та звільнення мьютексів тощо. (Гаразд, отже, ніхто, крім мене, не згадав мьютекси.) Якщо вилучено виняток, розгортання стеку природним чином очищає ресурси, використовувані методом.

Збір сміття - це програмне управління пам’яттю, хоча ви можете «збирати сміття» й іншими обмеженими ресурсами, якщо хочете. Явне звільнення їх має сенс у 99% випадків. Єдина причина використовувати RAII для чогось типу файлу чи сокета полягає в тому, що ви очікуєте, що використання ресурсу буде повним, коли метод повернеться.

Збір сміття також має справу з об’єктами, яким присвоєно купу , коли, наприклад, фабрика створює екземпляр об’єкта і повертає його. Наявність стійких об’єктів у ситуаціях, коли контроль повинен залишати область дії, - це те, що робить збір сміття привабливим. Але ви можете використовувати RAII на заводі, тому, якщо перед поверненням буде видано виняток, ви не втратите ресурси.

Я навіть чув, що збирач сміття може бути більш ефективним, оскільки він може звільняти більші шматки пам’яті за раз, замість того, щоб звільняти невеликі фрагменти пам’яті по всьому коду.

Це цілком здійсненно - і, насправді, насправді це зроблено - за допомогою RAII (або за допомогою звичайного malloc / free). Розумієте, вам не обов’язково завжди використовувати розподільник за замовчуванням, який вивільняє лише поштучно. У певному контексті ви використовуєте спеціальні розподільники з різними функціональними можливостями. Деякі розподільники мають вбудовану здатність звільняти все в певному регіоні розподілу, відразу, без необхідності повторювати окремі виділені елементи.

Звичайно, ви потім опиняєтесь у питанні про те, коли потрібно вивільнити все - чи потрібно використовувати ці розподільники (або плиту пам’яті, з якою вони пов’язані, RAIIed чи ні, і як.