Вопросы на собеседовании: Rust-разработчик

Передача String по значению переносит владение в параметр, поэтому старая привязка становится недоступной, а обычно уничтожить значение может только конечный инициализированный владелец.

• При перемещении переносится представление String на стеке без клонирования буфера в куче, а компилятор запрещает доступ через исходную привязку.
• Если функция возвращает String, владение переходит обратно и вызывающий код использует новую привязку без новой аллокации буфера.
• Если конечный инициализированный владелец достигает обычной точки уничтожения, Drop выполняется там один раз; mem::forget, утечки и process abort означают, что Rust не гарантирует вызов деструктора.
• Тип с реализацией Drop не может реализовывать Copy, иначе неявное дублирование нарушило бы гарантию единственного уничтожения.

Каждый вызов может получить более короткое повторное заимствование r, поэтому исходная изменяемая ссылка снова доступна после окончания дочернего заимствования.

• Для параметра типа &mut i32 компилятор может интерпретировать аргумент как &mut *r, а не окончательно перемещать r в первый вызов.
• Пока повторное заимствование активно, доступ через r приостановлен, поскольку более короткое дочернее заимствование временно держит используемый эксклюзивный доступ.
• Второй вызов создаёт новое непересекающееся заимствование после возврата из первой функции.
• Явное присваивание с перемещением r в другую привязку может поглотить исходную ссылку, поэтому это контекстное поведение, а не семантика Copy.

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

• Non-lexical lifetimes определяют активную область по реальным использованиям, поэтому печать ссылки перед push может завершить заимствование раньше.
• Использование ссылки после push сохраняет заимствование активным и запрещает изменение, поскольку рост Vec может реаллоцировать буфер и инвалидировать ссылку.
• Вызов drop для Copy-ссылки не создаёт особой семантики lifetime, поэтому меньший scope или настоящее последнее использование яснее завершают доступ.
• NLL сокращает заимствования, когда это позволяет поток данных, но никогда не сохраняет ссылку через потенциально инвалидирующее изменение.

Elision сначала назначает lifetimes входам и может вывести lifetime выхода только из единственного входа или из receiver.

• Первое правило даёт каждой входной ссылке без аннотации отдельный lifetime, поэтому x и y в first получают разные lifetimes.
• Второе правило назначает единственный входной lifetime всем выходным ссылкам без аннотации, когда входной lifetime ровно один.
• Третье правило назначает lifetime &self или &mut self всем выходам без аннотации, когда входных lifetimes несколько и один принадлежит receiver.
• Поэтому trim по второму правилу связывает output с s, first требует явной связи, а view по третьему правилу связывает output с self.

Я использую fn choose<'a>(x: &'a str, y: &'a str, pick_x: bool) -> &'a str, что ограничивает результат lifetime, допустимым для обоих входов.

• В месте вызова выведенный 'a не превышает более короткий доступный lifetime входов, поскольку вернуться может любая ветка.
• Аннотация связывает существующие заимствования, но не продлевает аллокации и не заставляет исходные значения жить одинаково долго.
• Если функция всегда возвращает x, y нужен независимый или выведенный lifetime, чтобы сигнатура не создавала ложную связь.
• Возвращаемый String подходит лучше, когда результат должен пережить оба заимствованных входа.

Bound 'static означает, что spawned future не должна содержать заимствований короче процесса, поэтому ей обычно следует владеть String или Arc на него.

• Владеющий String удовлетворяет T: 'static, поскольку не содержит заимствованной ссылки, хотя сам String всё ещё может быть уничтожен при завершении или отмене задачи.
• Значение типа &'static str отличается тем, что именно эта ссылка допустима в течение всей программы.
• Box::leak создаёт 'static-ссылку ценой намеренного вечного удержания аллокации, превращая обычное владение задачи в постоянную утечку.
• Перемещение String в async move блок или клонирование Arc даёт задаче явное конечное владение без утечки.

Общие ссылки ковариантны, аргументы функций контравариантны, а изменяемые ссылки инвариантны по типу значения из-за возможности записи.

• &'a T ковариантна по 'a и T, поэтому более долгое допустимое заимствование можно сократить там, где ожидается короткое.
• Указатель на функцию контравариантен по аргументу и ковариантен по результату, поскольку функция с более широким набором входов заменяет функцию с более узким.
• &mut T ковариантна по собственному lifetime, но инвариантна по T, потому что держатель ссылки может заменить содержащийся T.
• Если бы &mut &'long str преобразовывалась в &mut &'short str, в слот можно было бы записать короткую ссылку и позже прочитать её как 'long.

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

• Обычная safe struct не может связать lifetime внутренней &str с собственным String и одновременно разрешить операции перемещения, замены, уничтожения или реаллокации владельца.
• Offsets или Range<usize> переживают перемещения и позволяют методу заново создать slice после проверки границ UTF-8.
• Pinned self-referential design должен создавать ссылки после pinning, отключать Unpin при зависимости от адреса и скрывать каждую операцию, способную инвалидировать referent.
• Pin запрещает безопасное перемещение non-Unpin pointee, но не делает fields неизменяемыми и не мешает внутреннему String реаллоцироваться через открытый mutable API.

Option::take заменяет поле на None до возврата старого значения, поэтому заимствованный объект остаётся полностью инициализированным.

• Прямое перемещение non-Copy поля через &mut self оставило бы дыру, которую позже мог бы увидеть вызывающий код или пройти Drop.
• take реализует тот же ownership pattern, что и mem::replace с допустимым замещающим значением.
• Переданный Vec сохраняет существующую аллокацию и уничтожается конечным владельцем в воркере, если владение снова не переместится.
• Для обычного поля Vec mem::take оставляет Vec::default(), а replace лучше, если на месте нужен заранее выделенный буфер.

Rust сначала вызывает Drop::drop для bundle, затем уничтожает его поля в порядке объявления, а независимые локальные переменные уничтожает в обратном порядке объявления.

• Drop::drop ещё может обращаться ко всем полям, поскольку их автоматическое уничтожение начинается только после возврата метода.
• Перемещенная локальная переменная больше не уничтожается в старой привязке, поэтому Drop выполняет только её конечный владелец.
• При раскрутке panic инициализированные значения уничтожаются по раскручиваемому стеку, но panic = abort не выполняет такую очистку.
• Код должен явно кодировать зависимости завершения ресурсов, а не полагаться на неожиданный порядок объявления.

Реализация должна доказать корректность каждого допустимого использования обёртки при том межпоточном доступе, который обещает Send или Sync.

• Send разрешает перенос владения между потоками, а Sync означает возможность делить &Wrapper, поскольку &Wrapper реализует Send.
• Auto traits выводятся из полей, поэтому Rc запрещает Send и Sync, а raw-pointer поля требуют от автора явного доказательства внешнего контракта.
• unsafe impl Send может быть корректен для переносимого между потоками handle даже без Sync, если конкурентные вызовы через общие ссылки запрещены.
• Доказательство охватывает aliasing, гарантии потоков C-библиотеки, потоки callbacks, уничтожение и thread affinity, а не только наличие mutex.

Я выберу модель по стоимости критических секций и семантике обновлений, используя RwLock только при доказанной пользе параллельных чтений, а actor для последовательного протокола изменений.

• Arc<Mutex<_>> является самым простым выбором для коротких доступов и слабой конкуренции, а Arc разделяет только владение и не делает таблицу внутренне безопасной.
• Arc<RwLock<_>> допускает конкурентных readers, но fairness writers, длительность чтений и поведение реализации нужно измерять на реальной нагрузке 95/5.
• Actor владеет таблицей в одной задаче и принимает команды, убирая shared locking ценой очереди, дизайна сообщений и предела одного владельца.
• Публикация copy-on-write снимков через ArcSwap подходит для редких обновлений и чтений без lock ценой пересборки и удержания версий таблицы.

Я ограничу канал под измеренное окно всплеска и задам поведение producers после того, как длительный вход превысит пропускную способность consumer.

• Capacity 10 000 поглотит примерно одну секунду указанного дефицита в 10 000 событий в секунду, но конечная очередь не исправляет длительную перегрузку.
• send().await распространяет backpressure, приостанавливая producers, а try_send реализует явный сброс или объединение, когда ожидание недопустимо.
• reserve().await позволяет получить место до дорогого создания сообщения и не тратить работу во время насыщения.
• Глубину очереди, ожидание отправки, отклонённые события и throughput consumer нужно наблюдать вместе, чтобы рост памяти не становился сигналом перегрузки.

Я использую watch для последней конфигурации, broadcast только для best-effort fan-out audit events и oneshot для единственного startup reply.

• watch хранит одно текущее значение и уведомляет receivers об изменениях, поэтому медленный receiver может пропустить промежуточные конфигурации и прочитать последнюю.
• broadcast хранит ограниченную последовательность для каждого receiver, а отставший receiver получает ошибку Lagged, поэтому compliance-grade audit records сначала требуют durable log.
• oneshot переносит одно значение от одного sender к одному receiver без stream или повторной подписки.
• Ни один из них не заменяет mpsc, когда множество producers должны распределять каждый work item одному consumer.

Producer должен опубликовать указатель через Release, а consumer загрузить его через Acquire перед разыменованием инициализированного объекта.

• Release не даёт предшествующим записям инициализации переместиться после публикации, а совпавший Acquire, увидевший значение, делает эти записи видимыми consumer.
• Relaxed достаточно для независимого счётчика статистики, поскольку он гарантирует атомарность, но не порядок окружающих данных.
• SeqCst добавляет один глобальный порядок среди sequentially consistent операций, но не исправляет неверную схему владения или reclamation.
• Дизайн всё ещё должен доказывать публикацию только допустимых указателей и отсутствие readers после освобождения аллокации.

Я использую самые слабые orderings, сохраняющие доказательство синхронизации state machine, часто AcqRel при успехе и Acquire или Relaxed при неудаче.

• Успешная AcqRel-операция получает данные, опубликованные предыдущим состоянием, и публикует записи, связанные с новым состоянием.
• Неудачное сравнение выполняет только load, поэтому его ordering не может быть Release или AcqRel и зависит от необходимости получить данные увиденного значения.
• Возвращённый Err(actual) должен управлять retry, поскольку другой поток мог изменить состояние после чтения expected.
• Правильные orderings не решают ABA или безопасный memory reclamation, которым нужен отдельный дизайн версий, epochs или владения.

Свободные workers могут забирать runnable tasks у занятых, но не могут вытеснить задачу, которая блокируется или слишком долго работает внутри одного poll.

• Очереди workers улучшают locality, а внешние spawned или overflow tasks могут попадать в общие пути планирования, доступные другим workers.
• Spawned Send task может продолжиться на другом worker после await, поэтому thread-local предположения нельзя переносить через приостановку.
• Планирование Tokio кооперативно, поэтому futures должны возвращать Pending или иначе уступать управление за ограниченное время.
• Work stealing балансирует готовые задачи, но не создаёт CPU capacity и не спасает все workers, заблокированные синхронными вызовами.

Я перенесу блокирующий вызов в spawn_blocking и ограничу допуск к этой работе, чтобы workers executor и blocking queue не насыщались бесконтрольно.

• spawn_blocking использует blocking pool Tokio, чей большой верхний лимит по умолчанию не заменяет Semaphore, рассчитанный по CPU и latency budgets.
• После запуска blocking closure abort её JoinHandle не останавливает closure, поэтому deadlines требуют кооперативной отмены или отбрасывания позднего результата.
• Постоянный CPU-параллельный compression может лучше работать в отдельном Rayon pool с bounded bridge из async request handling.
• block_in_place доступен только на multi-thread runtime и исполняет blocking code на текущем worker после передачи других задач, поэтому ему тоже нужен контроль capacity.

poll должен организовать уведомление текущего Waker после появления прогресса и никогда не блокировать поток executor.

• Future проверяет readiness, регистрирует или обновляет текущий waker у источника и повторно проверяет состояние, если регистрация может конфликтовать с событием.
• Повторная проверка закрывает lost-wakeup окно, в котором readiness меняется между первой проверкой и регистрацией waker.
• Возврат Pending без будущего wake может навсегда усыпить задачу, а wake на каждом poll создаёт busy loop.
• poll получает Pin<&mut Self>, поскольку состояние future может зависеть от стабильного адреса, а Ready возвращает конечный output.

Я сохраню частичное состояние протокола вне отменяемой ветки и буду выбирать только операции, Drop которых не теряет зафиксированный прогресс.

• select! уничтожает futures проигравших веток, поэтому повторное создание не-cancellation-safe чтения в цикле может терять байты из приватного состояния future.
• Parser может владеть постоянным буфером, добавлять байты через cancellation-safe read primitive и отдельно декодировать полные frames.
• Долгоживущую future с внутренним прогрессом нужно создать и закрепить вне цикла, а не пересоздавать после каждого timeout.
• Cancellation safety означает сохранение инвариантов и документированной семантики перезапуска при Drop на любом await, а не async-завершение cleanup.