Функции g_object_ref/ g_object_unref соответственно увеличивают и уменьшают количество ссылок. Эти функции потоко-безопасны начиная с версии GLib 2.8. Подсчёт ссылок, что не удивительно, инициализируется с помощью g_object_new которая означает что вызывающая программа - текущий единственный владелец вновь созданной ссылки. Когда количество ссылок достигло нуля, то есть когда g_object_unref вызвал последний клиент содержащий ссылку на объект, вызываются dispose и finalize методы класса.

Наконец, после вызова finalize, вызывается g_type_free_instance для освобождения экземпляра объекта. В зависимости от политики распределения памяти при регистрации типа (через одну из функций g_type_register_*), объектный экземпляр памяти будет либо освобождён либо возвращён в пул для этого типа. Как только объект освобождён, если он был последним экземпляром типа, типовой класс будет уничтожен как описано в “Instantiable classed types: objects” и “Non-instantiable classed types: Interfaces.”.

Таблица ниже резюмирует процесс уничтожения GObject:

Слабые ссылки используются для контроля процесса финализации (finalization): g_object_weak_ref добавляет контрольный вызов который не содержит ссылок на объект, но который вызывается когда объект запускает свой метод размещения. Так же, каждая слабая ссылка может быть вызвана более одного раза в течение финализации объекта (так как размещение может выполняться больше одного раза в течение финализации объекта).

g_object_weak_unref может использоваться для удаления контролирующего вызова из объекта.

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

Заметьте: следующий раздел был написан благодаря James Henstridge. Я надеюсь что все ваши благодарности и проклятия будут адресованы непосредственно ему.

Модель управления памятью GObject была спроектирована для более лёгкой интеграции в существующий код используя "сборку мусора". Именно поэтому процесс уничтожения разделён на две фазы: первая фаза, выполняется в обработчике размещения и должна освободить все ссылки на другие объекты. Вторая фаза, выполняется обработчиком финализации и должна завершить процесс уничтожения объекта. Объектные методы должны быть способны выполняться без программных ошибок (то есть, без segfault :) между двумя фазами.

Эти два шага процесса уничтожения очень полезны для прекращения подсчёта ссылок в циклах. В течение обнаружения циклов во внешнем коде, как только циклы обнаружены, внешний код может вызвать g_object_dispose которая прекратит любые существующие циклы, так как она запустит обработчик размещения связанный с объектом и таким образом освободит все ссылки на другие объекты.

Внимательные читатели возможно поняли одно из правил обработчика размещения которое мы заявили немного раньше: обработчик размещения может быть вызван много раз. Предположим мы имеем цикличный подсчёт ссылок: объект A ссылается на B который в свою очередь ссылается на объект A. Предположим мы обнаружили цикл и нам необходимо уничтожить оба объекта. Один из способов сделать это - вызов g_object_dispose для одного из объектов.

Если объект A освободит все ссылки на другие объекты, значит он освободит ссылку на объект B. Если объект B не принадлежит ни кому, значит это его последняя ссылка что означает выполнение обработчика размещения объекта B, который в свою очередь освободит ссылку на объект A. Если это последняя ссылка A, запустится обработчик размещения A, который выполнится второй раз прежде чем будет вызван обработчик финализации A !

Пример выше, который может показаться немного замысловатым, действительно может произойти если ваш GObject обрабатывается языковой привязкой. Таким образом я предполагаю что правила описанные ранее для уничтожения объекта соблюдаются. Иначе, могут произойти Очень плохие вещи.