Що відбувається зі сміттям у C ++?

У Java є автоматичний GC, який час від часу зупиняє світ, але піклується про сміття на купі. Тепер додатки C / C ++ не мають цих STW заморожувань, а також використання їх пам'яті не зростає нескінченно. Як досягається така поведінка? Як опікуються мертвими предметами?

Програміст несе відповідальність за те, щоб об'єкти, створені ними, newбули видалені через delete. Якщо об’єкт створений, але не знищений до того, як останній вказівник чи посилання на нього не виходять за межі, він потрапляє через щілини і стає витоком пам'яті .

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

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

int main()
{
    int* variableThatIsAPointer = new int;
    int variableInt = 0;

    delete variableThatIsAPointer;
}

Тут ми створили дві змінні. Вони існують у Block Scope , як визначено {}фігурними дужками. Коли виконання буде виведено за межі цієї області, ці об'єкти будуть автоматично видалені. У цьому випадку, variableThatIsAPointerяк випливає з назви, - це вказівник на об’єкт в пам'яті. Коли він виходить за межі області, вказівник видаляється, але об’єкт, на який він вказує, залишається. Ось ми deleteцей об’єкт перед тим, як він вийде за межі, щоб переконатися у відсутності витоку пам'яті. Однак ми могли також пропустити цей покажчик в іншому місці і очікували, що він буде видалений пізніше.

Цей характер сфери дії поширюється на класи:

class Foo
{
public:
    int bar; // Will be deleted when Foo is deleted
    int* otherBar; // Still need to call delete
}

Тут застосовується той самий принцип. Нам не потрібно турбуватися про те, barколи Fooбуде видалено. Однак для otherBar, видаляється лише вказівник. Якщо otherBarєдиний дійсний вказівник на будь-який об’єкт, на який він вказує, ми, мабуть, мусимо deleteйого в Fooдеструкторі. Це концепція руху RAII

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

RAII також є типовою рушійною силою Smart Pointers . У стандартній бібліотеці C ++, це std::shared_ptr, std::unique_ptrі std::weak_ptr; хоча я бачив і використовував інші shared_ptr/ weak_ptrреалізації, які відповідають тим же концепціям. Для цього лічильник посилань відстежує кількість покажчиків на даний об’єкт, і автоматично deletes об'єкта, як тільки на нього більше немає посилань.

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

C ++ не має сміття.

Програми C ++ необхідні для утилізації власного сміття.

Щоб зрозуміти це, потрібні програмісти програм C ++.

Коли вони забувають, результат називається "витік пам'яті".

У системах C, C ++ та інших системах без збирача сміття розробнику пропонуються засоби за мовою та її бібліотеками, щоб вказати, коли пам'ять може бути відтворена.

Найбільш базовим засобом є автоматичне зберігання . Багато разів сама мова гарантує утилізацію предметів:

int global = 0; // automatic storage

int foo(int a, int b) {
    static int local = 1; // automatic storage

    int c = a + b; // automatic storage

    return c;
}

У цьому випадку компілятор відповідає за те, коли ці значення не використовуються, і відновлює сховище, пов'язане з ними.

При використанні динамічного зберігання в С традиційно виділяється пам'ять mallocі регенерується за допомогою free. У програмі C ++ пам'ять традиційно розподіляється за допомогою newта відновлюється за допомогою delete.

C протягом багатьох років не змінився, однак сучасний C ++ відмовляється newі deleteповністю, а замість цього покладається на бібліотечні засоби (які самі використовують newі deleteдоцільно):

• розумні покажчики найвідоміші: std::unique_ptrіstd::shared_ptr
• але контейнери набагато більш широке поширення на насправді: std::string, std::vector, std::map, ... все внутрішньо управляти динамічно розподіляє пам'яті прозоро

Якщо говорити про shared_ptr, то існує ризик: якщо цикл посилань формується, а не порушується, то там може відбуватися витік пам'яті. Розробник повинен уникати такої ситуації, найпростіший спосіб - уникнути shared_ptrвзагалі, а другий найпростіший - уникнути циклів на рівні типу.

Як результат, витоки пам'яті не є проблемою в C ++ , навіть для нових користувачів, якщо вони утримуються від використання new, deleteабо std::shared_ptr. Це на відміну від С, де необхідна непохитна дисципліна, і взагалі недостатня.

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

Висячий вказівник (або звисаючий посилання) - це небезпека, створена шляхом збереження вказівника або посилання на мертвий об'єкт. Наприклад:

int main() {
    std::vector<int> vec;
    vec.push_back(1);     // vec: [1]

    int& a = vec.back();

    vec.pop_back();       // vec: [], "a" is now dangling

    std::cout << a << "\n";
}

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

Не визначена поведінка є найбільшою проблемою із C та C ++ на сьогоднішній день з точки зору безпеки / коректності програм. Ви можете перевірити іржу на мову, де немає збирача сміття та не визначеної поведінки.

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

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

Слід зазначити, що у випадку C ++ поширене неправильне уявлення про те, що "потрібно робити керування пам'яттю вручну". Насправді ви зазвичай не керуєте пам'яттю у своєму коді.

Об'єкти фіксованого розміру (зі строком експлуатації)

У переважній більшості випадків, коли вам потрібен об'єкт, об’єкт буде мати певний термін служби у вашій програмі і створюється на стеці. Це працює для всіх вбудованих примітивних типів даних, а також для примірників класів і структур:

class MyObject {
    public: int x;
};

int objTest()
{
    MyObject obj;
    obj.x = 5;
    return obj.x;
}

Об'єкти стека автоматично видаляються, коли функція закінчується. У Java об'єкти завжди створюються на купі, і тому їх потрібно видалити за допомогою якогось механізму, наприклад, збирання сміття. Це не проблема для об'єктів стека.

Об'єкти, що керують динамічними даними (зі строком експлуатації)

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

class MyList {        
public:
    // a fixed-size pointer to the actual memory.
    int* listOfInts; 
    // constructor: get memory
    MyList(size_t numElements) { listOfInts = new int[numElements]; }
    // destructor: free memory
    ~MyList() { delete[] listOfInts; }
};

int listTest()
{
    MyList list(1024);
    list.listOfInts[200] = 5;
    return list.listOfInts[200];
    // When MyList goes off stack here, its destructor is called and frees the memory.
}

У коді, де використовується пам'ять, взагалі немає керування пам'яттю. Єдине, що нам потрібно переконатися - це те, що об’єкт, про який ми писали, має відповідний деструктор. Незалежно від того, як ми покинемо сферу дії listTest, будь то виняток або просто повернувшись з нього, деструктор ~MyList()буде викликаний, і нам не потрібно керувати жодною пам'яттю.

^{(Я думаю, що це смішне дизайнерське рішення використовувати двійковий оператор NOT~ , щоб позначити деструктор. Якщо використовується на числах, він обертає біти; аналогічно, тут вказується, що те, що зробив конструктор, перевернуто.)}

В основному всі об'єкти C ++, яким потрібна динамічна пам'ять, використовують цю інкапсуляцію. Він отримав назву RAII ("придбання ресурсів - ініціалізація"), що є досить дивним способом висловити просту думку про те, що об'єкти дбають про власний вміст; те, що вони набувають, - це їх очищення.

Поліморфні об'єкти та життя поза рамками

Тепер обидва ці випадки були для пам'яті, яка має чітко визначений термін експлуатації: Термін служби такий же, як і область застосування. Якщо ми не хочемо, щоб об’єкт закінчувався, коли ми залишаємо область, існує третій механізм, який може керувати пам'яттю для нас: розумний покажчик. Розумні покажчики також використовуються, коли у вас є екземпляри об'єктів, тип яких змінюється під час виконання, але які мають загальний інтерфейс або базовий клас:

class MyDerivedObject : public MyObject {
    public: int y;
};
std::unique_ptr<MyObject> createObject()
{
    // actually creates an object of a derived class,
    // but the user doesn't need to know this.
    return std::make_unique<MyDerivedObject>();
}

int dynamicObjTest()
{
    std::unique_ptr<MyObject> obj = createObject();
    obj->x = 5;
    return obj->x;
    // At scope end, the unique_ptr automatically removes the object it contains,
    // calling its destructor if it has one.
}

Існує ще один різновид розумного вказівника std::shared_ptrдля обміну об'єктами між кількома клієнтами. Вони видаляють об'єкт, що міститься, лише тоді, коли останній клієнт виходить за межі сфери, тому їх можна використовувати в ситуаціях, коли абсолютно невідомо, скільки клієнтів буде і скільки часу вони будуть використовувати об'єкт.

Підсумовуючи це, ми бачимо, що ви насправді не керуєтесь ручним управлінням пам'яттю. Все інкапсульовано, а потім опікується за допомогою повністю автоматичного управління пам’яттю на основі масштабів. У випадках, коли цього недостатньо, використовуються розумні покажчики, які інкапсулюють сиру пам'ять.

Вважається вкрай поганою практикою використання необмежених покажчиків як власників ресурсів у будь-якому місці коду C ++, виділення сировини поза конструкторами та необмежених deleteвикликів за межами деструкторів, оскільки ними практично неможливо керувати, коли трапляються винятки, і взагалі важко їх безпечно використовувати.

Найкраще: це працює для всіх типів ресурсів

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

Наприклад, функція, що блокує мютекс, зазвичай записується так у C ++:

void criticalSection() {
    std::scoped_lock lock(myMutex); // scoped_lock locks the mutex
    doSynchronizedStuff();
} // myMutex is released here automatically

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

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

Що стосується конкретно C, мова не дає інструментів для управління динамічно розподіленою пам'яттю. Ви абсолютно відповідальні за те, щоб переконатися, що кожен *allocмає freeдесь відповідне місце .

Там, де справи стають насправді неприємними, це коли розподіл ресурсів закінчується на середині; ти спробуєш ще раз, чи ти відкочуєшся назад і починаєш спочатку, чи повертаєшся назад та виходиш із помилкою, ти просто відшкодуєшся прямо і нехай ОС працює з цим?

Наприклад, ось функція виділення безперервного 2D масиву. Поведінка тут полягає в тому, що якщо помилка розподілу трапляється посередині процесу, ми повертаємо все назад і повертаємо індикацію помилки за допомогою вказівника NULL:

/**
 * Allocate space for an array of arrays; returns NULL
 * on error.
 */
int **newArr( size_t rows, size_t cols )
{
  int **arr = malloc( sizeof *arr * rows );
  size_t i;

  if ( arr ) // malloc returns NULL on failure
  {
    for ( i = 0; i < rows; i++ )
    {
      arr[i] = malloc( sizeof *arr[i] * cols );
      if ( !arr[i] )
      {
        /**
         * Whoopsie; we can't allocate any more memory for some reason.
         * We can't just return NULL at this point since we'll lose access
         * to the previously allocated memory, so we branch to some cleanup
         * code to undo the allocations made so far.  
         */
        goto cleanup;
      }
    }
  }
  goto done;

/**
 * We encountered a failure midway through memory allocation,
 * so we roll back all previous allocations and return NULL.
 */
cleanup:
  while ( i )         // this is why we didn't limit the scope of i to the for loop
    free( arr[--i] ); // delete previously allocated rows
  free( arr );        // delete arr object
  arr = NULL;

done:
  return arr;
}

Цей код непоганий для цих gotos, але, за відсутності будь-якого структурованого механізму обробки винятків, це майже єдиний спосіб вирішити проблему, не викладаючи повністю повністю, особливо якщо ваш код розподілу ресурсів вкладений більше ніж одна петля глибока. Це один з небагатьох разів, коли gotoнасправді є привабливим варіантом; в іншому випадку ви використовуєте купу прапорів та зайві ifзаяви.

Ви можете полегшити життя, написавши виділені функції розподільника / угоди для кожного ресурсу

Foo *newFoo( void )
{
  Foo *foo = malloc( sizeof *foo );
  if ( foo )
  {
    foo->bar = newBar();
    if ( !foo->bar ) goto cleanupBar;
    foo->bletch = newBletch(); 
    if ( !foo->bletch ) goto cleanupBletch;
    ...
  }
  goto done;

cleanupBletch:
  deleteBar( foo->bar );
  // fall through to clean up the rest

cleanupBar:
  free( foo );
  foo = NULL;

done:
  return foo;
}

void deleteFoo( Foo *f )
{
  deleteBar( f->bar );
  deleteBletch( f->bletch );
  free( f );
}

Я навчився класифікувати проблеми з пам'яттю на ряд різних категорій.

• Один раз капає. Припустимо, що програма під час запуску просочується 100 байт, тільки ніколи знову не протікає. Пригортання та усунення цих одноразових витоків - це приємно (мені подобається мати чистий звіт за можливістю виявлення витоку), але це не є істотним. Іноді виникають більші проблеми, на які потрібно напасти.

• Повторні витоки. Функція, яка викликається повторно протягом життя програми, яка регулярно просочує пам'ять великою проблемою. Ці крапельниці будуть мучити програму та, можливо, ОС, до смерті.

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

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

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

Програміст C ++ повинен реалізувати власну форму збору сміття там, де це необхідно. Якщо цього не зробити, це призведе до «витоку пам’яті». Досить поширеним є те, що мови "високого рівня" (наприклад, Java) мають вбудований збір сміття, але мови "низького рівня", такі як C і C ++, не мають.