Улучшает ли сборка мусора использование final для переменных в Java?

Question

Сегодня мы с коллегами обсуждаем использование ключевого слова final в Java для улучшения сборки мусора.

Например, если вы напишите такой метод, как:

public Double doCalc(final Double value)
{
   final Double maxWeight = 1000.0;
   final Double totalWeight = maxWeight * value;
   return totalWeight;  
}

Объявление переменных в методе final поможет сборщику мусора очистить память от неиспользуемых переменных в методе после выхода из метода.

Это правда?

Answer 1

Все методы и переменные могут быть переопределены по умолчанию в подклассах. Если мы хотим сохранить подклассы от переопределения членов суперкласса, мы можем объявить их как окончательные, используя ключевое слово final Например, final int a=10; final void display(){......} Создание метода final гарантирует, что функциональность, определенная в суперклассе, никогда не будет изменена. Точно так же значение окончательной переменной никогда не может быть изменено. Конечные переменные ведут себя как переменные класса.

Answer 2

Единственный раз, когда я предпочитаю объявлять локальные переменные как окончательные, это когда:

• У меня есть , чтобы сделать их окончательными, чтобы их можно было использовать совместно с каким-то анонимным классом (например: создать поток демона и разрешить ему доступ к некоторому значению из включающего метода)

• Я хочу, чтобы сделал их окончательными (например, какое-то значение, которое не должно / не должно быть переопределено по ошибке)

Помогают ли они в быстрой уборке мусора?
AFAIK объект становится кандидатом в коллекцию GC, если он имеет нулевые сильные ссылки на него, и в этом случае также нет гарантии, что они будут немедленно собраны мусором. В общем, сильная ссылка считается умершей, когда она выходит из области видимости, или пользователь явно переназначает ее на нулевую ссылку, таким образом, объявив их окончательными, это означает, что ссылка будет существовать до тех пор, пока метод не существует (если область его действия явно не сужена до определенный внутренний блок {}), потому что вы не можете переназначить конечные переменные. Так что я думаю, что сборщик мусора 'final' может ввести нежелательную возможную задержку.

Answer 3

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

Answer 4

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