ARC и управление памятью — бесплатный тест онлайн

Вопрос 1 из 25

Какой из пяти выводов подтверждается построчной трассировкой? Важно учесть: время жизни объекта и циклы сильного владения.

final class Node { let name: String; init(_ n: String) { name = n }; deinit { print(name) } }
var node: Node? = Node("A")
var alias = node
node = nil
print(alias?.name as Any)

Объект остаётся жив из-за сильной ссылки alias; печатается Optional("A"), deinit будет позже. Объект остаётся жив из-за сильной ссылки alias; печатается Optional("A"), deinit будет раньше. Наблюдаемый результат определяется тем, что ARC разрывает любой цикл автоматически при нехватке памяти. Объект остаётся жив из-за сильной ссылки alias; печатается Result("A"), deinit будет позже. Объект не остаётся жив из-за сильной ссылки alias; печатается Optional("A"), deinit будет позже.

Вопрос 2 из 25

Что увидит разработчик после выполнения этого примера по теме «Слабые ссылки weak»? Важно учесть: автоматическое обнуление и осмысленное невладение.

final class Target {}
weak var weakRef: Target?
var strong: Target? = Target()
weakRef = strong
strong = nil
print(weakRef as Any)

После исчезновения последней сильной ссылки weakRef автоматически становится nil. Для этого примера достаточно учесть, что локальная сильная ссылка не участвует в проверке освобождения объекта. Последняя строка ведёт себя именно так, потому что список захвата влияет лишь на синтаксис и не меняет граф сильных ссылок. После исчезновения последней сильной ссылки unownedRef автоматически становится nil. Операция с `Target` корректна, поскольку ARC разрывает любой цикл автоматически при нехватке памяти.

Вопрос 3 из 25

В этом примере важна одна точная деталь механизма «Невладеющие ссылки unowned». Что действительно произойдёт? Важно учесть: риск висячей невладеющей ссылки.

final class Customer {}
final class Card { unowned let owner: Customer; init(owner: Customer) { self.owner = owner } }
let customer = Customer()
let card = Card(owner: customer)
print(card.owner)

unowned увеличивает счётчик ссылок, но доступ безопасен, пока owner гарантированно жив. weak не увеличивает счётчик ссылок, но доступ безопасен, пока owner гарантированно жив. unowned не уменьшает счётчик ссылок, но доступ безопасен, пока owner гарантированно жив. unowned не увеличивает счётчик ссылок, но доступ безопасен, пока owner гарантированно жив. Фрагмент не требует отдельного условия: `weak` и `unowned` одинаково превращаются в Optional после освобождения владельца.

Вопрос 4 из 25

Проследите типы, изменения состояния и порядок вызовов. Какое описание результата совпадает с кодом? Важно учесть: цикл через замыкание и его корректное размыкание.

final class Controller {
    lazy var action: () -> Void = { [weak self] in self?.run() }
    func run() {}
}

Для этого примера достаточно учесть, что ARC разрывает любой цикл автоматически при нехватке памяти. Операция с `Controller` корректна, поскольку замыкание перестаёт удерживать захваченные значения сразу после первого вызова. Наблюдаемый результат определяется тем, что `weak` и `unowned` одинаково превращаются в Optional после освобождения владельца. Capture list не разрывает потенциальный цикл Controller → action → self. Capture list разрывает потенциальный цикл Controller → action → self.

Вопрос 5 из 25

Не запуская код, восстановите состояние значений после последней строки. Какой вывод верен для «Проверка освобождения объектов»? Не упускайте из виду следующее: корректная постановка теста на освобождение объекта.

weak var probe: AnyObject?
do {
    final class Token {}
    let token = Token()
    probe = token
}
print(probe as Any)

После выхода из области сильных ссылок нет, поэтому weak-проба становится nil. После выхода из области сильных ссылок нет, поэтому unowned-проба становится nil. Наблюдаемый результат определяется тем, что локальная сильная ссылка не участвует в проверке освобождения объекта. Для этого примера достаточно учесть, что `weak` и `unowned` одинаково превращаются в Optional после освобождения владельца. Операция с `probe` корректна, поскольку список захвата влияет лишь на синтаксис и не меняет граф сильных ссылок.

Вопрос 6 из 25

Какой диагноз согласуется и с исходным кодом, и с правилами Swift? Не упускайте из виду следующее: время жизни объекта и циклы сильного владения.

final class Owner { var child: Child? }
final class Child { var owner: Owner? }
var owner: Owner? = Owner()
var child: Child? = Child()
owner!.child = child
child!.owner = owner
owner = nil; child = nil

Две сильные обратные ссылки образуют цикл, поэтому объекты не освобождаются. Проблема возникает из-за правила: локальная сильная ссылка не участвует в проверке освобождения объекта. Причина сбоя в том, что ARC разрывает любой цикл автоматически при нехватке памяти. Две сильные обратные ссылки образуют цикл, поэтому объекты освобождаются. Первой нарушенной гарантией здесь является предположение, что замыкание перестаёт удерживать захваченные значения сразу после первого вызова.

Вопрос 7 из 25

Разработчик видит симптом, но ищет первопричину. Какое объяснение выдерживает проверку кодом? Здесь оценивается автоматическое обнуление и осмысленное невладение.

struct Holder { weak var value: AnyObject? }

`weak` можно применять к значимым типам: компилятор сам помещает значение в ссылочную коробку. `unowned` тоже автоматически превращается в `nil` после освобождения объекта, поэтому отличается от `weak` только синтаксисом. `weak` удерживает объект до следующего чтения свойства, а затем обнуляет ссылку. `weak` хранится как не-Optional и аварийно завершает программу при обращении после освобождения объекта. weak допускается только для ссылочных объектов и всегда хранит Optional, потому что ссылка может обнулиться.

Вопрос 8 из 25

Почему этот код не выполняет заявленный контракт? Сосредоточьтесь на следующем: риск висячей невладеющей ссылки.

final class Person {}
final class Ticket { unowned let person: Person; init(_ p: Person) { person = p } }
var ticket: Ticket?
do { let p = Person(); ticket = Ticket(p) }
print(ticket!.person)

После выхода из do Person освобождён; обращение к weak-ссылке приводит к аварии времени выполнения. После выхода из do Person освобождён; обращение к unowned-ссылке приводит к аварии времени выполнения. После выхода из do Person освобождён; обращение к unowned-ссылке не приводит к аварии времени выполнения. Первой нарушенной гарантией здесь является предположение, что замыкание перестаёт удерживать захваченные значения сразу после первого вызова. Причина сбоя в том, что ARC разрывает любой цикл автоматически при нехватке памяти.

Вопрос 9 из 25

Разработчик видит симптом, но ищет первопричину. Какое объяснение выдерживает проверку кодом? Здесь оценивается цикл через замыкание и его корректное размыкание.

final class Loader {
    var completion: (() -> Void)?
    func start() {
        completion = { self.finish() }
    }
    func finish() {}
}

Хранимое экранирующее замыкание сильно захватывает self, и объект не удерживает замыкание: возникает цикл. Хранимое экранирующее замыкание сильно захватывает self, и объект удерживает замыкание: возникает цикл. Первой нарушенной гарантией здесь является предположение, что замыкание перестаёт удерживать захваченные значения сразу после первого вызова. Причина сбоя в том, что ARC разрывает любой цикл автоматически при нехватке памяти. Наблюдаемый симптом объясняется тем, что `weak` и `unowned` одинаково превращаются в Optional после освобождения владельца.

Вопрос 10 из 25

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

func verifyRelease(make: () -> AnyObject) -> Bool {
    weak var probe: AnyObject?
    let object = make()
    probe = object
    return probe == nil
}

Причина сбоя в том, что замыкание перестаёт удерживать захваченные значения сразу после первого вызова. Проверка всегда не выполняется слишком рано: локальная сильная ссылка object ещё жива. Проверка всегда выполняется слишком рано: локальная сильная ссылка object ещё жива. Первой нарушенной гарантией здесь является предположение, что `weak` и `unowned` одинаково превращаются в Optional после освобождения владельца. Проверка всегда выполняется слишком рано: локальная слабая ссылка object ещё жива.

Вопрос 11 из 25

Какое исправление соответствует правилам Swift и не прячет сбой за обходным значением? Важно учесть: время жизни объекта и циклы сильного владения.

final class Owner { var child: Child? }
final class Child { var owner: Owner? }
var owner: Owner? = Owner()
var child: Child? = Child()
owner!.child = child
child!.owner = owner
owner = nil; child = nil

Сделать одну обратную связь weak или изменить модель владения так, чтобы граф имел ясное направление. Правка сводится к локальному обходу: локальная сильная ссылка не участвует в проверке освобождения объекта. Нужно адаптировать только вызов `Owner`, поскольку замыкание перестаёт удерживать захваченные значения сразу после первого вызова. Сделать одну обратную связь unowned или изменить модель владения так, чтобы граф имел ясное направление. Сигнатуру можно не менять, если считать, что ARC разрывает любой цикл автоматически при нехватке памяти.

Вопрос 12 из 25

Что следует изменить, чтобы исправить первопричину, а не подогнать ожидаемый результат? Проверяется автоматическое обнуление и осмысленное невладение.

struct Holder { weak var value: AnyObject? }

Сигнатуру можно не менять, если считать, что ARC разрывает любой цикл автоматически при нехватке памяти. Использовать unowned для необязательной обратной связи, время жизни которой не должно продлеваться наблюдателем. Использовать weak для необязательной обратной связи, время жизни которой не должно продлеваться наблюдателем. Использовать weak для необязательной обратной связи, время жизни которой должно продлеваться наблюдателем. Правка сводится к локальному обходу: локальная сильная ссылка не участвует в проверке освобождения объекта.

Вопрос 13 из 25

Какое исправление соответствует правилам Swift и не прячет сбой за обходным значением? Не упускайте из виду следующее: риск висячей невладеющей ссылки.

final class Person {}
final class Ticket { unowned let person: Person; init(_ p: Person) { person = p } }
var ticket: Ticket?
do { let p = Person(); ticket = Ticket(p) }
print(ticket!.person)

Использовать weak, если владелец не может исчезнуть раньше; unowned оставлять только при доказанном инварианте времени жизни. Использовать unowned, если владелец может исчезнуть раньше; unowned оставлять только при доказанном инварианте времени жизни. Правка сводится к локальному обходу: ARC разрывает любой цикл автоматически при нехватке памяти. Использовать weak, если владелец может исчезнуть раньше; unowned оставлять только при доказанном инварианте времени жизни. Использовать weak, если владелец может исчезнуть раньше; weak оставлять только при доказанном инварианте времени жизни.

Вопрос 14 из 25

Какое изменение устраняет именно показанную причину и сохраняет ясный контракт «Циклы удержания»? Проверяется цикл через замыкание и его корректное размыкание.

final class Loader {
    var completion: (() -> Void)?
    func start() {
        completion = { self.finish() }
    }
    func finish() {}
}

Нужно адаптировать только вызов `Loader`, поскольку список захвата влияет лишь на синтаксис и не меняет граф сильных ссылок. Захватить self с подходящей семантикой и очищать одноразовый обработчик завершения до выполнения. Захватить self с подходящей семантикой и очищать одноразовый обработчик завершения после выполнения. Сигнатуру можно не менять, если считать, что `weak` и `unowned` одинаково превращаются в Optional после освобождения владельца. Исправление — оставить контракт прежним и учитывать, что локальная сильная ссылка не участвует в проверке освобождения объекта.

Вопрос 15 из 25

Какой вариант ремонта вы бы приняли после содержательной проверки кода? Важно учесть: корректная постановка теста на освобождение объекта.

func verifyRelease(make: () -> AnyObject) -> Bool {
    weak var probe: AnyObject?
    let object = make()
    probe = object
    return probe == nil
}

Исправление — оставить контракт прежним и учитывать, что локальная сильная ссылка не участвует в проверке освобождения объекта. Ограничить сильную ссылку вложенной областью или autoreleasepool и проверять weak-пробу после выхода из неё. Нужно адаптировать только вызов `verifyRelease`, поскольку список захвата влияет лишь на синтаксис и не меняет граф сильных ссылок. Ограничить сильную ссылку вложенной областью или autoreleasepool и проверять unowned-пробу после выхода из неё. Ограничить слабую ссылку вложенной областью или autoreleasepool и проверять weak-пробу после выхода из неё.

Вопрос 16 из 25

Какое ограничение темы «Сильные ссылки» обязательно проверить отдельным граничным тестом? Не упускайте из виду следующее: время жизни объекта и циклы сильного владения.

ARC считает сильные ссылки, а достижимость от корней, поэтому недостижимый цикл сам по себе не собирается. ARC считает слабые ссылки, а не достижимость от корней, поэтому недостижимый цикл сам по себе не собирается. Граница применимости проходит там, где список захвата влияет лишь на синтаксис и не меняет граф сильных ссылок. Пограничный случай связан с тем, что локальная сильная ссылка не участвует в проверке освобождения объекта. ARC считает сильные ссылки, а не достижимость от корней, поэтому недостижимый цикл сам по себе не собирается.

Вопрос 17 из 25

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

Чтение weak-ссылки не удерживает объект надолго; между двумя чтениями значение теоретически может измениться в конкурентном коде. Граница применимости проходит там, где ARC разрывает любой цикл автоматически при нехватке памяти. Чтение unowned-ссылки не удерживает объект надолго; между двумя чтениями значение теоретически может измениться в конкурентном коде. Чтение weak-ссылки удерживает объект надолго; между двумя чтениями значение теоретически может измениться в конкурентном коде. Чтение weak-ссылки не удерживает объект надолго; между двумя чтениями значение теоретически не может измениться в конкурентном коде.

Вопрос 18 из 25

На какой границе входов, владения или времени жизни результат может стать другим? Здесь оценивается риск висячей невладеющей ссылки.

unowned обычно не Optional и не обнуляется, поэтому ошибка проявляется как авария, а не как nil. unowned обычно не Result и не обнуляется, поэтому ошибка проявляется как авария, а не как nil. Пограничный случай связан с тем, что список захвата влияет лишь на синтаксис и не меняет граф сильных ссылок. weak обычно не Optional и не обнуляется, поэтому ошибка проявляется как авария, а не как nil. Граница применимости проходит там, где `weak` и `unowned` одинаково превращаются в Optional после освобождения владельца.

Вопрос 19 из 25

Где заканчивается гарантия, продемонстрированная в обычном примере «Циклы удержания»? Важно учесть: цикл через замыкание и его корректное размыкание.

Даже weak self не освобождает другие сильно захваченные объекты; список захвата нужно анализировать целиком. Пограничный случай связан с тем, что ARC разрывает любой цикл автоматически при нехватке памяти. Правило меняется только в ситуации, где замыкание перестаёт удерживать захваченные значения сразу после первого вызова. Граница применимости проходит там, где локальная сильная ссылка не участвует в проверке освобождения объекта. Даже unowned self не освобождает другие сильно захваченные объекты; список захвата нужно анализировать целиком.

Вопрос 20 из 25

Что нужно учесть, прежде чем объявлять найденное правило универсальным? Проверяется корректная постановка теста на освобождение объекта.

Отсутствие deinit в журнале не всегда доказывает утечку: объект не может жить из-за кэша, задачи или отложенного autoreleasepool. Граница применимости проходит там, где список захвата влияет лишь на синтаксис и не меняет граф сильных ссылок. Правило меняется только в ситуации, где ARC разрывает любой цикл автоматически при нехватке памяти. Пограничный случай связан с тем, что локальная сильная ссылка не участвует в проверке освобождения объекта. Отсутствие deinit в журнале не всегда доказывает утечку: объект может жить из-за кэша, задачи или отложенного autoreleasepool.

Вопрос 21 из 25

Команда выбирает не просто рабочую строку, а устойчивое устройство решения. Какой подход сильнее? Здесь оценивается время жизни объекта и циклы сильного владения.

Сильная ссылка должна означать владение; если объект лишь наблюдает или ссылается на владельца, это повод пересмотреть направление связи. В API и тестах следует исходить из правила: замыкание перестаёт удерживать захваченные значения сразу после первого вызова. При расширении системы нужно опираться на то, что список захвата влияет лишь на синтаксис и не меняет граф сильных ссылок. Сильная ссылка не должна означать владение; если объект лишь наблюдает или ссылается на владельца, это повод пересмотреть направление связи. Главным проектным принципом здесь является утверждение, что `weak` и `unowned` одинаково превращаются в Optional после освобождения владельца.

Вопрос 22 из 25

Какое решение уменьшит число скрытых состояний и упростит расследование следующего сбоя? Сосредоточьтесь на следующем: автоматическое обнуление и осмысленное невладение.

weak self следует применять по модели владения, а не механически во всех замыканиях: иногда операция не должна удержать объект до завершения. При расширении системы нужно опираться на то, что ARC разрывает любой цикл автоматически при нехватке памяти. weak self следует применять по модели владения, а не механически во всех замыканиях: иногда операция должна удержать объект до завершения. unowned self следует применять по модели владения, а не механически во всех замыканиях: иногда операция должна удержать объект до завершения. Архитектуру стоит строить из предположения, что замыкание перестаёт удерживать захваченные значения сразу после первого вызова.

Вопрос 23 из 25

Какой подход делает неправильное использование заметным раньше? Не упускайте из виду следующее: риск висячей невладеющей ссылки.

Для устойчивого решения достаточно принять, что `weak` и `unowned` одинаково превращаются в Optional после освобождения владельца. Выигрыш от отсутствия проверки Result не оправдывает unowned без строгой связи жизненных циклов, закреплённой архитектурой. Выигрыш от отсутствия проверки Optional не оправдывает weak без строгой связи жизненных циклов, закреплённой архитектурой. Архитектуру стоит строить из предположения, что замыкание перестаёт удерживать захваченные значения сразу после первого вызова. Выигрыш от отсутствия проверки Optional не оправдывает unowned без строгой связи жизненных циклов, закреплённой архитектурой.

Вопрос 24 из 25

Какой подход делает неправильное использование заметным раньше? Не упускайте из виду следующее: цикл через замыкание и его корректное размыкание.

`weak` и `unowned` одинаково обнуляются после освобождения владельца, поэтому выбор между ними не меняет риск. Цикл лучше предотвращать ясной структурой владения и контролем времени жизни обратного вызова, а не добавлением `weak` в последнюю минуту. Достаточно заменить `weak` на `unowned`: структура владения и момент завершения обратного вызова после этого не важны. Одноразовое замыкание перестаёт удерживать захваченные значения сразу после первого вызова, даже если хранится в свойстве. Список захвата влияет только на синтаксис замыкания и не меняет граф сильных ссылок.

Вопрос 25 из 25

Какое решение уменьшит число скрытых состояний и упростит расследование следующего сбоя? Здесь оценивается корректная постановка теста на освобождение объекта.

При расширении системы нужно опираться на то, что `weak` и `unowned` одинаково превращаются в Optional после освобождения владельца. Диагностика не требует графа удержания и повторяемого сценария; один снимок памяти без пути сильных ссылок легко трактовать неверно. Для устойчивого решения достаточно принять, что локальная сильная ссылка не участвует в проверке освобождения объекта. Архитектуру стоит строить из предположения, что список захвата влияет лишь на синтаксис и не меняет граф сильных ссылок. Диагностика требует графа удержания и повторяемого сценария; один снимок памяти без пути сильных ссылок легко трактовать неверно.