Phantom Reference

Weak Reference

SoftReference

Нужно объявить тот тип объекта, который мы хотим поместить в окружение мягкой ссылки SoftReference <Stack> s;

s = new SoftReference (new Stack());

s = NULL;//в этом случае будет разорвана связь. В таком случае SoftReference становится недоступным, как и объект

Пока памяти много, эти объекты сборке мусора не подвергаются. Если мы достигли границ, то мягкие ссылки удаляются

! мягкая ссылка не будет удаляться до тех пор, пока есть свободная память

s.getObject.push (…)//s.getObject может вернуть NULL.

Зачем это нужно??

Это нужно для формирования перечня объектов, которые может быть нужны (сохранить их в памяти неплохо, но необязательно).

Пример: клиент-серверные системы (контент, например пользователь был на одной странице, перешел на другую, что делать со старой?? Пока есть память, сохраняем страницы. Или отмена действий по Ctrl+Z)

У меня много свободной памяти, я храню хоть 1000 шагов.

Если картинка 100 mpx, то мы не сможем сохранить много, поэтому когда память закончится, сработает сборка мусора.


 

Она не переживает даже первой сборки мусора (при первой сборке мусора удаляется)

Зачем нужна?
то же, что и SoftReference, только мы не ждём, пока память закончится

Повторяет WeakReference, только по другому работают деструкторы. Если мы открываем для Java-машины какой-то ресурс, то при уничтожении объекта ОС не волнует, что объект удалён и она продолжает считать, что Java-машина использует ресурсы. Было бы неплохо закрыть ресурс. Для этого есть finalize-метод объекта. Он срабатывает в тот момент, когда объект физически считается удалённым. Во время финализации мы имеем право обращаться ко всем объектам системы в принципе (можем хранить внутри ссылки на другие объекты)
объект-зомби может передать ссылку на себя же и ОПА, объект ожил!

Сколько сборок мусора он пережил в состоянии «зомби», столько раз будет выполняться finalize().

Объекты, на которые мы потеряли классическую ссылку, потеряны в доступе.

Когда объект мягкий или гибкий теряют ссылки и становятся зомби (S=NULL), сами ссылки (на которые ссылается soft или weak) попадают в массив объектов, связанных с s. Происходит после сборки мусора. Попадает до финализации (и после он может ожить)

В Phantom Reference он перемещается тогда, когда прошел стадию финализации (он полностью очищен, уже после финализации, с потустороннего мира).

Это предназначено для написания Native-функций Java-машины.

Таненбаум «Операционные системы»

Чепелев будет спрашивать о проблемах клинча по этой книге

Обнаружение клинча (ОС не имеет таких инструментов)
Что с ним делать? (как обнаружения нет, так и решения нет)

В современных ОС для будущего потенциала задач клинча, идёт транзакционное фиксирование, то есть ОС в пределах одной транзакции всё запоминает. Если что-то не получилось, будет произведет откат транзакций. Реализовано с помощью двойной буферизации (открываются новые буфера и в них будет записываться всё то, что я делаю). Если откат – то буфера сбрасываются, если всё успешно, то из буферов записывается в переменные, ресурсы.

1. Объект живой (на него есть ссылки. Сборщики мусора маркируют как живой, он спасается копированием)

2. Потеря ссылок

3. Проходит какое-то время, начинает работать сборщик мусора

4. Трассировка с маркировкой (объект не получает маркер «живой объект», то есть «неживой»), но оказывается, что

a. Finalize нет -> место считается пустым (объект не будет спасаться операцией копирования)

b. Finalize есть -> маркировка типа «зомби (нефинализированный, неживой)», и пока он не финализируется, будет копироваться от сборки к сборке

5. Копирование непустого места