Ниже — сжатое, но содержательное сопоставление четырёх подходов по четырём критериям: производительность, предсказуемость задержек, типичные ошибки и влияние на дизайн API.
1) Ручное выделение/освобождение (C: malloc/free)
- Производительность: минимальные накладные расходы при корректной реализации; операции выделения/освобождения обычно $O(1)$ амортизировано, но фрагментация и системные аллокации могут увеличить задержки.
- Предсказуемость задержек: высокая (детерминировано) — освобождение происходит ровно когда программист вызвал free; нет "неожиданных пауз" от рантайма.
- Ошибки: легко появляются утечки (забыли free), висячие указатели/use-after-free (освободили, но продолжают использовать), двойное освобождение; нет встроенной защиты от ошибок.
- Влияние на API: API должен явно документировать контракт владения (кто должен free), часто появляется пара функций create/destroy; сложнее безопасно реализовывать RAII-подобные идиомы без доп. механизмов.
2) Сборщик мусора (Java, Go)
- Производительность: накладные расходы на управление памятью и перемещение объектов (в движущихся GC) и/или фоновые потоки; хорошая пропускная способность для краткоживущих объектов (generational), но постоянная память и CPU для GC.
- Предсказуемость задержек: низкая в классическом stop-the-world GC; современные concurrent/real-time GC (G1, ZGC, Go concurrent GC) сильно снижают паузы, но тяжело обеспечить жёсткие реальной-времени границы в общем случае.
- Ошибки: утечки возможны при удержании ссылок (logical leaks), висячих указателей практически исключены; циклы не проблема для GC.
- Влияние на API: упрощает моделирование владения — объекты свободно передаются; финализаторы/деструкторы ненадёжны (недетерминированные), поэтому API часто требует явного закрытия (close/Dispose) для внешних ресурсов; поддерживаются слабые ссылки для кешей.
3) Счётчик ссылок (ARC/RC в Swift, CPython)
- Производительность: инк/дек счётчика при каждом присваивании/освобождении — постоянная накладная операция $O(1)$ на изменение ссылки; в многопоточной среде нужны атомарные операции — значительно дороже.
- Предсказуемость задержек: де-факто детерминированное освобождение (момент деаллокации предсказуем), но операции инк/дек могут создавать помехи/контеншн; циклы образуют утечки, если не применять слабые ссылки.
- Ошибки: утечки из-за циклических ссылок; dangling pointer обычно не возникает в управляемом коде с RC, но возможны при взаимодействии с нативным/неуправляемым кодом.
- Влияние на API: необходимость поддерживать weak/weakable ссылки и ясно указывать циклообразующие структуры; API часто проектируют с явными weak-примитивами или делением на сильные/слабые связи; ARC в Swift делает большинство вещей прозрачными, но API дизайну полезно избегать замыканий, захватывающих self без weak.
4) Система владения и заимствования (Rust)
- Производительность: минимальная накладная во времени выполнения — большинство проверок выполняются компилятором (нулевой рантайм-кост для владения/заимствования); стэк-алокация и оптимизации возможны широко.
- Предсказуемость задержек: высокая и детерминированная — освобождение по выходу области видимости; нет GC-пауз и нет периодических фоновых работ.
- Ошибки: компилятор предотвращает многие классы ошибок (use-after-free, data races при safe code); утечки возможны при использовании Rc циклов, mem::forget или unsafe-кода, но они явны/редки.
- Влияние на API: API явно отражает владение через сигнатуры (\& и \&mut, перенос владения), что делает контракты времени жизни видимыми в интерфейсе; побуждает к переносу владения, заимствованиям и менее частому использованию глобального состояния; детерминированный Drop позволяет безопасно инкапсулировать ресурсы.
Краткое сравнение по ключевым свойствам
- Производительность (runtime накладные): C/Rust (низкие) < RC (умеренные, особенно с атомиками) < GC (зависит: может быть высока при интенсивном сборе).
- Предсказуемость задержек: C/Rust (высокая) > RC (детерминировано, но атомарности влияют) > GC (наихудшая без специализированного GC).
- Утечки: возможны во всех; GC и RC без циклов уменьшают риск; RC подвержен циклам; Rust/C могут иметь утечки при ошибках программиста.
- Висячие указатели: характерны для C; практически исключены в GC/RC при корректном коде и в Rust при safe-коде.
- Дизайн API: GC упрощает владение/передачу, но требует явного закрытия внешних ресурсов; RC требует weak/strong стратегии; Rust делает время жизни частью API; C вынуждает явное управление контрактами.
Практические рекомендации (кратко)
- Нужна максимальная производительность и предсказуемость — Rust (или C с осторожностью).
- Нужна максимальная разработческая скорость и удобство — GC-языки (Java/Go) или Python; учитывать финализацию/close для ресурсов.
- Требуется детерминированное освобождение ресурсов при минимальном рантайме — выбирать RAII/ownership (Rust/C++) или ARC с careful weak-ссылками (Swift).
- Много потоков с частыми ссылочными обновлениями — избегать атомарного RC; предпочесть ownership/GC или алгоритмы с локальными аллокациями.
Если нужно — дам короткие примеры кода/шаблоны API для каждого подхода.