В документе на сайте thinkdast.com/listadd необходимо написать реализацию и провести тестирование для подтверждения.

Последнее: написать основную часть метода remove. Документ находится по адресу: thinkdast.com/listrem. Когда вы закончите, все тесты должны пройти успешно.

Как только ваша реализация заработает, сравните её с версией в каталоге solution репозитория.

3.6. Аннотации о сборке мусора

В предыдущих упражнениях MyArrayList число увеличивалось при необходимости, но не уменьшалось. Массив никогда не собирал мусор, и элементы не собирались до уничтожения самого списка.

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

Вот моя реализация метода clear:

public void clear() {
    head = null;
    size = 0;
}

Когда мы устанавливаем head равным null, мы удаляем ссылку на первый Node. Если нет других ссылок на Node (их не должно быть), он будет собран сборщиком мусора. Затем второй узел будет удалён из-за отсутствия ссылки, поэтому он также будет собран. Этот процесс продолжается до тех пор, пока все узлы не будут собраны.

Каким образом следует классифицировать метод clear? Сам по себе метод содержит две операции, выполняющиеся за постоянное время, так что кажется, что это операция постоянного времени. Однако когда вы вызываете его, вы заставляете сборщик мусора выполнять некоторую работу, которая пропорциональна количеству элементов. Поэтому, возможно, его следует считать линейным!

Это пример того, что иногда называют «багом производительности»: программа делает правильные вещи в этом смысле, но она не соответствует ожидаемому уровню производительности. В таких языках, как Java, где происходит много работы за кулисами, например сборка мусора, такие баги бывает трудно обнаружить.