Кратко: у C — ручное управление через malloc/free (макс. контроль, мин. безопасность), у Java — автоматический сборщик мусора (GC) (высокая безопасность от большинства ошибок, но непредсказуемые паузы и накладные расходы), у Rust — модель владения и заимствований с проверками на этапе компиляции (приближенно нулевая накладная, статическая гарантия памяти/параллелизма в большинстве случаев).

Ниже — по пунктам (без формальных таблиц).

C (malloc/free)

Безопасность:
Нет автоматических гарантий: возможны use-after-free, double-free, dangling pointer, буферные переполнения, тайминговые/гонки при многопоточности.Большой набор уязвимостей для эксплойтов (RCE через переполнение буфера и т.п.).Производительность:
Очень высокая предсказуемость и контроль: можно оптимизировать выделение/освобождение под задачу.Нулевой накладной "рантайм": только то, что вы написали.Пригодность:
Встраиваемые: отлично подходит при жестких ресурсах; много платформных SDK на C.Системные (ядра, драйверы): стандарт де-факто.Серверные: подходит там, где нужен максимальный контроль; но затраты на безопасность и отладку высоки.Типичные ошибки (примеры):
Use-after-free:
int p = malloc(sizeof(int));
free(p);
p = 42; // UB, потенциально эксплойтDouble free:
free(p); free(p);Утечка памяти:
ptr = malloc(...); / забыли free / Буферная переполнение:
char buf[8]; strcpy(buf, user_input);Как снижать риски: ASAN/Valgrind, статический анализ (clang-tidy), безопасные абстракции, код-ревью, режимы сборки с защитами (canaries, PIE, DEP).

Java (GC)

Безопасность:
Защищён от большинства классов ошибок управления памятью (нет произвольных указателей, use-after-free, buffer overflow в Java-объектах).По-прежнему возможны логические ошибки, утечки через удержание ссылок, а также уязвимости в нативном коде (JNI).Производительность:
GC добавляет накладные расходы и использует больше памяти (больший working set).Современные сборщики (G1, ZGC, Shenandoah) минимизируют паузы, но для жестких требований по задержкам поведение может быть непредсказуемым.Пригодность:
Встраиваемые: обычно плохо — JVM имеет большой размер и требования к памяти/CPU (исключения: специализированные JVM для embedded).Системные: как правило не подходит для ядра/драйверов.Серверные: очень хорош — богатая экосистема, простота разработки, высокопроизводительные приложения при правильной настройке GC.Типичные ошибки (примеры):
Утечка через удержание ссылок:
static List cache = new ArrayList<>();
cache.add(obj); // obj никогда не GC пока в cacheНепредвиденные паузы/latency spikes из‑за GC в реальном‑времени.OutOfMemoryError при ошибочной политике хранения/кеширования.Проблемы с finalize() (непредсказуемое время вызова) — предпочитать try-with-resources/AutoCloseable.Как снижать риски: профилирование памяти, слабые ссылки (WeakReference), tune GC, использование пулов/streaming вместо накопления, избегать нативного кода там, где возможно.

Rust (владение и заимствования)

Безопасность:
Статические гарантии: в большинстве случаев Rust исключает use-after-free, data races и двойное освобождение на этапе компиляции.Нулевой указатель как правило исключён (Option), нет скрытых UB в безопасном Rust.Возможна UB при использовании unsafe — но unsafe локализован и требует явного разрешения разработчиком.Производительность:
"Zero-cost abstractions": производительность близка к C/C++.Детерминированное освобождение при выходе области видимости (RAII-like): predictable latency, нет GC-пауз.Возможны небольшие накладки (refcounting, runtime checks) если используются Rc/RefCell/Box, но при правильном выборе структур — минимально.Пригодность:
Встраиваемые: отлично подходит — минимальный рантайм, no-GC, язык поддерживает bare-metal.Системные: очень хорошо — Rust всё активнее используется для системного ПО (включая драйверы, части ядра).Серверные: отлично — низкие задержки, безопасность, современный стек (async).Типичные ошибки (примеры):
Крутые ошибки компиляции из‑за правил заимствования (не runtime, но UX friction).Утечки через циклические ссылки с Rc/RefCell:
let a = Rc::new(RefCell::new(...));
let b = Rc::new(RefCell::new(...));
a.borrow_mut().other = Some(Rc::clone(&b));
b.borrow_mut().other = Some(Rc::clone(&a)); // цикл — память не будет освобожденаUB внутри unsafe-блоков:
unsafe {
let p = raw_ptr.as_mut().unwrap();
// ошибки с выравниванием/владением/жизненным циклом — UB
}mem::forget или std::mem::ManuallyDrop могут привести к утечкам/нарушению ожиданий.Как снижать риски: пользоваться безопасным Rust, ограничивать unsafe и покрывать тестами; Miri для выявления неправильного использования unsafe; clippy; sanitizers (ASAN/LSAN/TSAN) при необходимости.

Короткое сравнение по направлениям

Встраиваемые:
C: традиционный выбор, минимальная зависимость, но риск ошибок.Java: обычно нет (JVM heavy).Rust: современная альтернатива C — безопасность без GC.Системные (ядра/драйверы):
C: широко применяется.Java: не подходит.Rust: всё более подходящий выбор (меньше уязвимостей), но требует осторожности при unsafe.Серверные приложения:
C: при микросервисах редко; нужен большой набор вспомогательных библиотек.Java: зрелый выбор для больших JVM-приложений, богатая экосистема и отлаживаемость.Rust: отличен для высокопроизводительных, низколатентных сервисов; экосистема быстро растёт.

Рекомендации при выборе

Нужна максимальная предсказуемость/минимальный рантайм (embedded, realtime) → Rust или C (Rust предпочтителен, если нужна безопасность).Нужна зрелая платформа с высокой продуктивностью команды и готовой экосистемой (веб‑серверы, большие бэкенды) → Java.Нужно низкоуровневое системное программирование (ядро, драйверы) → C или Rust (Rust уменьшит количество классов уязвимостей).Везде: если выбираете C, инвестируйте в инструменты обнаружения ошибок; если Java — в профилирование и настройку GC; если Rust — в понимание правил владения и аккуратное использование unsafe.

Если нужно, могу привести более детальные код‑примеры ошибок и способы их обнаружения/исправления для каждой модели.