Умные указатели в Rust: Box, Rc, Arc

enum List {
    Cons(i32, Box<List>),
    Nil,
}

let a = Rc::new(5);
let b = Rc::clone(&a);
Rc::strong_count(&a); // 2

Проверьте себя

Пять вопросов из банка по этой подтеме. Всего их 12, остальные разбираются в тренажёре.

1. #rs_smart_pointers1 / 5
   Чем Rc<T> отличается от Arc<T>?

   A)Rc считает ссылки обычным счётчиком, Arc — атомарным для потоков

   B)Rc живёт на стеке, Arc — в куче

   C)Rc освобождает память сразу, Arc откладывает до сборки мусора

   D)Rc для неизменяемых данных, Arc разрешает менять значение внутри

   показать ответ и разбор

   +A)Rc считает ссылки обычным счётчиком, Arc — атомарным для потоков

   // разбор: Функционально это один и тот же подсчёт ссылок, разница в цене синхронизации. У Rc счётчик неатомарный и потому дешёвый, но тип не Send — компилятор не пустит его в другой поток. Arc платит атомарными операциями и потому пригоден для многопотока. Мутабельности не даёт ни тот, ни другой: нужен RefCell или Mutex внутри.

2. #rs_smart_pointers2 / 5
   Зачем в однопоточном коде связка Rc<RefCell<T>>?

   A)Rc хранит данные, RefCell кэширует их копию для быстрого чтения

   B)Rc даёт несколько владельцев, RefCell — правку через &

   C)Rc защищает от гонок, RefCell от паник при обращении

   D)Такая связка нужна, чтобы значение пережило текущую функцию

   показать ответ и разбор

   +B)Rc даёт несколько владельцев, RefCell — правку через &

   // разбор: Rc позволяет нескольким местам владеть значением, но отдаёт только & — менять нельзя. RefCell добавляет внутреннюю изменяемость: правило XOR проверяется в рантайме, а не компилятором. Вместе получается разделяемое изменяемое состояние в одном потоке — типовая основа графов и деревьев с обратными ссылками.

3. #rs_smart_pointers3 / 5
   Два узла ссылаются друг на друга через Rc. Что произойдёт при выходе из области видимости?

   A)Сборщик циклов обнаружит их и освободит память

   B)Компилятор запретит такую конструкцию на этапе сборки

   C)Память освободится: Rc отслеживает циклы через счётчик слабых ссылок

   D)Счётчики не дойдут до нуля, деструкторы не вызовутся — утечка

   показать ответ и разбор

   +D)Счётчики не дойдут до нуля, деструкторы не вызовутся — утечка

   // разбор: Взаимные Rc держат друг друга: после выхода из области видимости счётчики падают с двух до единицы и там застревают. Память не освобождается, Drop не вызывается — классическая утечка, и она безопасна с точки зрения языка. Лечится Weak: обратную ссылку делают слабой, она в счётчик владения не входит.

4. #rs_smart_pointers4 / 5
   Что вернёт Weak::upgrade(), если сильных ссылок на значение уже не осталось?

   A)Rc с новым счётчиком: upgrade воскрешает значение

   B)Ссылку на освобождённую память — отсюда unsafe в сигнатуре

   C)None: данные освобождены, слабая ссылка знает об этом

   D)Панику: обращение к мёртвому значению считается ошибкой

   показать ответ и разбор

   +C)None: данные освобождены, слабая ссылка знает об этом

   // разбор: Weak не удерживает данные: при обнулении сильного счётчика значение уничтожается, а служебный блок с счётчиками живёт, пока есть слабые ссылки. Поэтому upgrade возвращает Option — Some, пока значение живо, и None после. Так делают кэши и обратные ссылки «ребёнок → родитель», не создавая циклов.

5. #rs_smart_pointers5 / 5
   Что напечатает код?

   let a = Rc::new(String::from("x"));
   println!("{}", Rc::strong_count(&a));
   {
       let _b = Rc::clone(&a);
       println!("{}", Rc::strong_count(&a));
   }
   println!("{}", Rc::strong_count(&a));

   A)1, затем 1, затем 1

   B)1, затем 2, затем 1

   C)1, затем 2, затем 2

   D)2, затем 3, затем 2

   показать ответ и разбор

   +B)1, затем 2, затем 1

   // разбор: Rc::clone не копирует строку, а увеличивает счётчик сильных ссылок: внутри блока владельцев двое. На выходе из блока _b уничтожается, счётчик падает обратно до единицы, и значение живо, пока он не дошёл до нуля. Отсюда и цена приёма: сам клон дешёвый, но каждый требует парного drop, а взаимные ссылки счётчик до нуля не доводят вовсе.