Ссылка набора = пустой указатель в наконец блоке?
Мой коллега устанавливает ссылку на null в наконец блоках. Я думаю, что это не имеет смысла.
public Something getSomething() {
JDBCConnection jdbc=null;
try {
jdbc=JDBCManager.getConnection(JDBCTypes.MYSQL);
...
}
finally {
JDBCManager.free(jdbc);
jdbc=null; // <-- Useful or not?
}
}
Что Вы думаете о нем?
7 ответов
Вы правы, jdbc является локальной переменной, поэтому когда метод getSomething() вернется, jdbc выйдет из области видимости и будет подлежать сборке мусора, что фактически то же самое, что установить его в null. Поэтому нет смысла устанавливать переменную в null, когда она выходит из области видимости в следующей строке кода.
Хорошей практикой является ограничение переменных до минимально необходимой области видимости, например, если переменная нужна только внутри цикла for, то объявите ее в цикле for, и она будет подлежать сбору мусора, когда код выйдет из цикла for. Это, а также снижение сложности ваших методов, уменьшает необходимость вообще устанавливать локальные переменные в null, и, как преимущество, ваш код становится более модульным, его легче читать и поддерживать.
Да, это практически полная чушь. Обычно это делается для того, чтобы "помочь" сборщику мусора, но это не настоящая помощь, поскольку ссылка все равно очищается. Хотя вреда от этого тоже нет, по крайней мере, для виртуальной машины - ваши глаза и здравомыслие - совсем другое дело.
Однако пример не возвращает Нечто. Если пример неполный, и после блока finally действительно есть утверждения, то установка jdbc в null может послужить сдерживающим фактором для использования, а NPE, который возникнет сразу, сообщит о любом использовании после блока finally.
Если после блока finally будет больше кода, а не просто завершить метод, это может помочь сборщику мусора очистить его.
Поскольку это локальная переменная, она все равно выйдет из области видимости. Это нонсенс.
Если бы это была переменная экземпляра (переменная-член) долгоживущего объекта, она могла бы быть полезной, поскольку в противном случае она могла бы помешать сборщику мусора утилизировать объект.
В этом частном случае, технически говоря, это действительно бесполезно. Когда метод возвращается, jdbc больше не существует и не будет содержать ссылку на соединение, поэтому это не повлияет на сборку мусора.
Это вопрос стиля программирования. Есть небольшое преимущество, если однажды вы добавите больше кода после блока finally. Тогда сразу становится очевидным, что вы не можете больше использовать jdbc , потому что он был освобожден JDBCManager.
Итак, да, это хорошая практика - аннулировать ссылки на удаленные ресурсы.
как уже было написано, в данном случае это бесполезно, потому что метод заканчивается после finally.
Я бы сделал это, если есть код, следующий за try-finally, чтобы в конечном итоге предотвратить его использование. И есть (очень редкие) ситуации, когда это может помочь.
Взгляните на эту статью: Java Memory Puzzle
, то он должен установить для всех локальных переменных значение null во всех методах перед возвратом.
JVM, вероятно, все равно оптимизирует линию, поэтому она не оказывает никакого влияния на время выполнения.