Как написать код, помогающий сборщику мусора

Сборщик мусора очень эффективен и ловок в своей работе, но мы можем усилить его способность собирать мусор, указывая на null переменные и объекты, которые больше не используются и на них больше нет ссылок. При работе с файлами используйте методы close() и flush(). И при обработке потоков уничтожайте поток, когда он не используется.

Сборщик мусора — это «задача», которая периодически сканирует ваши объекты, чтобы обнаружить, что не используется (на самом деле это механизм для эмуляции машины с бесконечной памятью).

По этой причине, когда вы держите ссылку на экземпляр объекта, который вам больше не нужен, вы должны установить для него значение null, чтобы сборщик мусора знал, что вас больше не интересует этот экземпляр (и, возможно, его потомки).

Это не означает, что вы должны устанавливать каждую переменную в null после использования, но вы должны следить за полями. Поскольку в Java нет шаблона удаления (см. здесь для получения дополнительной информации), вы должны разработать свои API, чтобы имитировать его: когда вы закончите использовать экземпляр объекта, содержащий ссылку, которую вы хотите освободить, вы должны добавить соответствующий метод совершить такое действие.

Рассмотрим следующий пример:

class MyClass1
{
    int Field1;
    int Field2;
    int Field3;
    int Field4;
}

class MyClass2
{
    private MyClass1 m_MyReference;

    public MyClass2()
    {
        m_MyReference = new MyClass1();
    }

    public void DoSomething()
    {
        // do something here that uses m_MyReference.
    }
}

Если экземпляр MyClass2 удерживается, но какой-либо другой доступный экземпляр вашей программы (например, синглтон или какой-либо экземпляр, находящийся в настоящее время в стеке), вы никогда не освободите память, связанную с MyClass1, поскольку на него все еще ссылается m_MyReference.

Это плохо? Это зависит от того, что MyClass2 и MyClass1 действительно делают.

Если вы знаете, что MyClass2 может иметь очень долгий срок службы, и вы хотите сохранить ссылку на MyClass2, но освободить память, связанную с MyClass1, вам нужно сделать что-то похожее на код ниже:

class MyClass2
{
    private MyClass1 m_MyReference;

    public MyClass2()
    {
        m_MyReference = new MyClass1();
    }

    public void DoSomething()
    {
        // do something here that uses m_MyReference.
    }

    public void Dispose()
    {
        m_MyReference = null;
    }

}

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

Помните, что простое присвоение null переменной или полю не освобождает память автоматически. Сборщик мусора является асинхронным и запускается по своему усмотрению. Надеюсь, что дал идею, не вдаваясь слишком глубоко.

Странно сформулирован вопрос. ГК не нуждается в помощи в своей работе. Он будет работать с любыми ограничениями, наложенными на него, или потерпит неудачу, если ограничения не могут быть соблюдены.

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

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

Наивный код может быть более читабельным, но менее производительным. Если вашей целью является легко читаемый код, то выполнение сложных оптимизаций, снижающих нагрузку на сборщик мусора, может привести к обратным результатам, и поэтому «помощь сборщику мусора» не является самоцелью.

Теперь, если ваша цель — улучшить некоторые показатели производительности, то некоторые оптимизации также включают в себя написание кода, который уменьшает работу, выполняемую подсистемой управления памятью (распределение + GC). Некоторые возможные оптимизации включают отказ от финализаторов, обнаружение утечек памяти, сокращение ненужных выделений, отказ от огромных массивов Object[], настройку параметров GC, покупку лучшего оборудования и сокращение времени жизни объектов. Какая оптимизация применима, зависит от приложения и может быть лучше всего выяснена с помощью профилировщиков, ведения журнала GC и связанных с ними