Кратко и по существу — по каждому языку: модель владения, сборка мусора/управление памятью, безопасность указателей, типичные ошибки и механизмы их предотвращения.
C
- Владение / управление: полностью ручное: выделение/освобождение через `malloc`/`free`, стековые объекты освобождаются при выходе из области видимости.
- Сборка мусора: нет.
- Безопасность указателей: сырые указатели, арифметика указателей, нет проверки границ, нет ограничений на алиасинг.
- Классические ошибки: буферные переполнения, выход за границы массива, use‑after‑free (использование после освобождения), double free, dangling pointers, утечки памяти, неопределённое поведение (UB) при арифметике вне диапазона, неверной конверсии типов.
- Механизмы предотвращения (практические/внешние): статический анализ, динамические санитайзеры (AddressSanitizer, Valgrind), компиляторные флаги и UBSan, защитные механизмы ОС (ASLR, DEP/NX, stack canaries), соглашения кодирования, ручное использование безопасных библиотек. В языке самих средств безопасности почти нет — ответственность на программисте.
Java
- Владение / управление: владение неявное; объекты располагаются в куче, ссылки на объекты — управление через GC.
- Сборка мусора: автоматический сборщик мусора (несколько алгоритмов: generational, G1, ZGC и т.п.), освобождает неиспользуемые объекты.
- Безопасность указателей: нет сырых указателей и арифметики; есть ссылки и проверяемые индексы массивов (ArrayIndexOutOfBoundsException), нет прямого доступа к памяти.
- Классические ошибки: утечки памяти из‑за удержания ссылок (long‑lived collections), NullPointerException, переполнение стека/кучи (StackOverflowError / OutOfMemoryError), ошибки при взаимодействии с нативным кодом (JNI) могут вернуть проблемы памяти.
- Механизмы предотвращения: автоматический GC предотвращает use‑after‑free и double‑free; рантайм‑проверки (проверка границ массивов, отсутствие арифметики указателей) снижают классы ошибок; Java Memory Model задаёт правила видимости и упорядочения для многопоточности (но логические гонки всё ещё возможны и приводят к некорректному поведению, хотя не к UB в смысле C).
Rust
- Владение / управление: явная система владения и заимствований: каждый объект имеет владельца; при уходе владельца объект освобождается; передача владения — перенос (move); заимствования через `&T` (неизменяемое) и `&mut T` (изменяемое).
- Сборка мусора: нет глобального GC по умолчанию; сборка памяти детерминирована через RAII/Drop и систему владения. Для разделяемого владения есть `Rc`/`Arc` (счётчики ссылок).
- Безопасность указателей: в safe Rust только безопасные ссылки без арифметики и с гарантией отсутствия data races и висячих ссылок; raw‑указатели (`*const`, `*mut`) и unsafe-блоки позволяют обойти проверки, но обязуют программиста.
- Классические ошибки: в safe коде практически исключены use‑after‑free, double‑free, dangling pointer, неконтролируемый алиасинг/мутация; возможны утечки памяти (например, через циклы `Rc` или `mem::forget`), в `unsafe` можно допустить все ошибки C.
- Механизмы предотвращения: borrow checker и система времён жизни (lifetimes) гарантируют корректность заимствований на этапе компиляции; `Option`/нет null по умолчанию предотвращают null‑доступы; типовая система и отсутствие неинициализированной памяти (в safe коде) блокируют многие ошибки; для случаев реального разделяемого изменяемого состояния — `RefCell` делает runtime‑проверку заимствований (паника при нарушении).
Сравнительная сводка (ключевые различия)
- Контроль vs удобство: C даёт максимальный контроль и скорость, но полную ответственность программисту; Java даёт удобство и автоматическое освобождение памяти — меньше низкоуровневых ошибок, но возможны утечки и непредсказуемые паузы GC; Rust стремится дать безопасность памяти и высокую производительность без GC через систему владения и проверок на этапе компиляции.
- Use‑after‑free и double‑free: в C — частые; в Java — невозможны (GC); в Rust — невозможны в safe коде, возможны в unsafe.
- Буферные переполнения: в C — обычная проблема; в Java — предотвращаются проверками границ; в Rust — предотвращаются в safe коде, возможны в unsafe.
- Null‑доступ: C/Java — возможен (NPE в Java, UB/null access в C); Rust — отсутствует по умолчанию, используйте `Option`.
- Data races: C — UB возможен при гонках; Java — гонки приводят к логическим ошибкам, JMM ограничивает поведение; Rust — компилятор запрещает data races в safe коде (правило Send/Sync).
- Утечки: возможны во всех трёх (в C — частые; в Java — из‑за удержания ссылок; в Rust — возможны при циклах Rc или явном забывании).
Коротко: C — гибкость + риск (ручное управление, UB); Java — безопасность от многих ошибок памяти благодаря GC и рантайм‑проверкам, но с возможными утечками и паузами GC; Rust — строгая компиляторная безопасность памяти без GC в safe коде, с небольшими накладными расходами и возможностью обойти защиту через unsafe при необходимости.