Как я заметил, многие, начинающие программировать на Java, не вполне чётко представляют себе, как следует управлять ресурсами на этом языке. В данной статье я попытался изложить своё видение на этот аспект программирования.
Что может, а чего не может GC.
Одним из особенностей языка Java является автоматическая сборка мусора - пресловутый Garbage Collector (сокращённо - GC). GC - это фоновый процесс, который занимается поиском и освобождением неиспользуемых объектов. Много копий было сломано в дискуссиях, хорошо это или плохо, причём существенные аргументы есть как у сторонников, так и у противников этой технологии. Но я не об этом. Примем существование GC как данность и рассмотрим особенности программирования в данной среде.
Одним из следствий наличия GC (и отсутствия размещения объектов в стеке) является отсутствие деструкторов, аналогичным существующих в C++ - автоматически вызываемых методов для уничтожения объектов по выходу из области видимости. Вместо них есть другие механизмы, которые позволяют добиться того же самого.
Другим следствием является необходимость следить за ссылками на объекты, потому как GC именно по наличию ссылки на объект определяет его нужность. Для возможности управления строгостью ссылок в JDK 1.2 был введён новый пакет java.lang.ref, классы которого позволяет создавать так называемые "слабые" ссылки на объекты. Это особенно полезно для реализации кэширования объектов.
Начитавшись рекламных статей, может показаться, что очисткой ресурсов вообще не стоит заниматься - всё сделает GC. Тут важно понимать, что в понятие ресурсов входит не только оперативная память, но так же и многое другое. Например - открытые файлы, сокеты, ResultSet-ы и Statement-ы в JDBC, и т.д. С очисткой памяти GC в последних JVM справляется довольно неплохо, но вот освобождение других ресурсов, как правило, нельзя делать асинхронно. В противном случае легко получить так называемые "плавающие" ошибки, которые то появляются, то исчезают.
Возможно вы искали - Курсовая работа: Java: Русские буквы и не только…
Над разработкой алгоритма работы GC довольно долго корпели разработчики, так что иногда его поведение может показаться несколько странным. В частности, он может освобождать объекты в произвольном порядке, никак не связанном с порядком их создания или очистки последних ссылок на них. Так же, для примера, в JDK 1.3, GC начинает освобождать объекты только тогда, когда текущий пул памяти заполняется. При этом одновременно, этот пул расширяется, пока не дойдёт до заданного верхнего лимита. Одновременно учитывается время последнего доступа и размер объекта. И т.д. и т.п.
По умолчанию верхний лимит пула зависит от системы. В JDK 1.3 он равен 64 мегабайтам. В некоторых случаях лучше снизить эту планку, особенно когда на машине памяти не очень много - тем самым программа быстрей дойдёт до этого лимита и начнёт использовать память повторно.
Большинство JVM не отдают обратно системе память, которую они забрали под пул. Я знаю только одну JVM, которая это делает - это Microsoft JVM. Все остальные хапают до указанного лимита.
Деструкторов нет. А что вместо?
Многие программисты (особенно только что пересевшие с C++), видят замену деструкторов в виде методов finalize. Это не есть правильно. Во первых, этот метод не вызовется, пока на объект имеются ссылки. Нет гарантии, что он вызовется тогда, когда вам это нужно. Он может вообще никогда не вызваться. Есть, конечно, метод System.runFinalizersOnExit(), но он уже давно deprecated из-за возможных deadlock-ов. Как справедливо заметил Bruce Eckel в замечательной книжке Thinking in Java метод finalize стоит использовать только для того, чтобы освободить память (или другой, не очень критичный ресурс), выделенную в native методах. Для прочих же ресурсов следует добавить явный вызов метода очистки ресурсов (он может называться по-разному - close, dispose, cleanup, и т.д.), внутри конструкции finally. Внутри finally - для того, чтобы не прозевать какое-нибудь исключение. Пример типичных конструкций:
OutputStream out = new FileOutputStream(...);
Похожий материал - Реферат: Введение в C#: классы
try
{
...
}
finally { out.close(); }
Очень интересно - Реферат: Регулярные выражения в perl
PreparedStatement stmt = ...;
try
{
stmt.setInt(1,...);
ResultSet rs = stmt.executeQuery();
Вам будет интересно - Реферат: Отладка программ пользователя в Tubro Pascal
try
{
...
}
finally { rs.close(); }
Похожий материал - Курсовая работа: Компьютерная подготовка
}
finally { stmt.close(); }
Если Вы будете писать программы в таком стиле, то многие проблемы обойдут Вас стороной - поверьте, я уже наступал на эти грабли. :-)
Memory Leak в Java и как с ним бороться.
Казалось бы - какие могут быть Memory Leak (утечки памяти), когда есть GC. Но, тем не менее, они возможны. Эти утечки отличаются по своему происхождению от утечек в C/C++ (таких в Java вообще быть не может, за исключением возможных ошибок в JVM, но этот вариант мы здесь не рассматриваем). Они возникают из-за забытых ссылок.