Краткий ответ

RefCell<T> переносит проверку правил заимствования с этапа компиляции на время выполнения. Он разрешает либо несколько неизменяемых заимствований, либо одно изменяемое, но при нарушении этого правила во время выполнения вызывает панику или возвращает ошибку через try_borrow и try_borrow_mut.

Это не отменяет безопасность памяти: доступ контролируется специальным механизмом внутренней изменяемости, а конфликтующие заимствования не приводят к неопределённому поведению.

Исторический контекст

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

Для таких случаев Rust предоставляет внутреннюю изменяемость. RefCell<T> предназначен главным образом для однопоточных сценариев, где программист принимает на себя ответственность за то, что возможное нарушение правил будет обработано во время выполнения.

Постановка проблемы

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

Если разрешить произвольную запись через общую ссылку без проверок, можно получить одновременное чтение и изменение либо несколько конфликтующих записей. Это нарушило бы гарантии Rust и могло бы привести к неопределённому поведению.

Подробное решение

RefCell<T> хранит значение и состояние активных заимствований. Вызов borrow создаёт охрану неизменяемого заимствования, а borrow_mut — охрану изменяемого заимствования. Пока живут несколько объектов Ref, разрешены только чтения; при существующем RefMut любой другой доступ запрещён.

Охрана освобождает заимствование при уничтожении. Поэтому продолжительность заимствования определяется временем жизни возвращённого объекта-охранника, а не только областью видимости самого RefCell.

use std::cell::RefCell;

fn increment(value: &RefCell<i32>) {
    *value.borrow_mut() += 1;
}

fn main() {
    let value = RefCell::new(10);
    increment(&value);
    println!("{}", value.borrow());
}

В примере функция получает неизменяемую ссылку на RefCell, но изменяет находящееся внутри число. borrow_mut временно предоставляет изменяемый доступ; после завершения выражения охрана освобождается, и значение можно снова читать.

Если вызвать borrow_mut, пока активно другое заимствование, обычный borrow_mut завершит программу паникой. Методы try_borrow и try_borrow_mut позволяют обработать конфликт как результат Result, что предпочтительнее в коде, где конфликт является ожидаемым сценарием.

RefCell<T> не делает тип потокобезопасным и не реализует Sync. Для общего состояния между потоками применяют, например, Mutex<T> или RwLock<T>, которые используют синхронизацию и блокировки. Для типов, реализующих Copy, иногда достаточно Cell<T>, поскольку он предоставляет операции чтения и замены без выдачи обычных ссылок на внутреннее значение.

Ситуация из практики

В однопоточном редакторе документа узлы дерева могут иметь ссылки на связанные узлы, а обработчик события должен менять внутреннее состояние узла во время обхода. Статическое владение такой структурой может оказаться слишком сложным из-за циклических или динамически создаваемых связей.

Один вариант — перестроить модель данных так, чтобы состояние передавалось явно и владение оставалось уникальным. Это даёт максимально сильные compile-time гарантии, но может усложнить обход графа и увеличить количество служебного кода.

Другой вариант — использовать Rc<RefCell<Node>>. Rc управляет совместным владением в одном потоке, а RefCell позволяет временно изменять узел через общую ссылку. Решение удобно для небольшого однопоточного графа, но конфликт заимствований обнаруживается только во время выполнения, поэтому тесты должны покрывать такие пути.

Для многопоточного редактора этот вариант непригоден: потребуется потокобезопасная схема с Arc<Mutex<Node>>, Arc<RwLock<Node>> или иная архитектура. Она устраняет проблему потоков, но добавляет стоимость синхронизации и риск блокировок.

Что кандидаты часто упускают

Может ли RefCell<T> привести к неопределённому поведению при конфликте заимствований?

Нет, обычный интерфейс RefCell проверяет состояние заимствований и при конфликте паникует либо возвращает ошибку. Паника может быть нежелательной с точки зрения поведения приложения, но сама по себе не является нарушением гарантий безопасной памяти. Проблемы неопределённого поведения возможны только при самостоятельном нарушении требований небезопасного кода, лежащего ниже этой абстракции.

Почему RefCell<T> нельзя считать заменой Mutex<T>?

RefCell<T> рассчитан на один поток и не предоставляет межпоточной синхронизации. Его проверки защищают от логического конфликта заимствований внутри потока, но не координируют одновременный доступ разных потоков. Mutex<T> дополнительно сериализует доступ между потоками и потому имеет другую стоимость и другую модель блокировок.

Что именно освобождает заимствование, созданное borrow_mut?

Заимствование освобождает объект-охранник RefMut, возвращённый методом borrow_mut, когда этот объект уничтожается. Если сохранить охранник в переменной, изменяемый доступ будет продолжаться дольше, чем при использовании его только внутри короткого выражения. Поэтому иногда нужно ограничить область видимости охранника или явно завершить её, чтобы получить следующий доступ к RefCell.