В Linux и, возможно, в некоторых Unixes, вы можете использовать lsof для «вывода списка открытых файлов», открытых приложением. Вы, вероятно, увидите увеличение их числа, если в вашем приложении есть утечка файловых дескрипторов. Вы можете даже достичь (по умолчанию) потолка в 1024 маркера.
В Windows есть несколько бесплатных подобных утилит где-то в комплекте SysInternals; Я думаю, что это называется «ручками» или «ручками» или что-то в этом роде. Я пойду посмотрю, смогу ли я найти это ...
РЕДАКТИРОВАТЬ: Ах, вот оно: Ручка .
РЕДАКТИРОВАТЬ: Недавно я столкнулся с аналогичной, неясной проблемой с сокетами (которые также являются своего рода дескриптором файла, по крайней мере, в Linux): оказывается, что даже если соединение было закрыто, связанный дескрипторы файлов не будут выпущены, пока Java не выполнит сборку мусора. Наше приложение не занимало много памяти, поэтому часто дескрипторы соединения накапливались быстрее, чем они были очищены. Мы решили проблему, вставляя System.gc() время от времени. Падение производительности было терпимым по отношению к полной неисправности, когда у приложения заканчивались ручки.
РЕДАКТИРОВАТЬ: На более высоком уровне библиотека JRE, конечно, «просто» Java-код, а исходный код AFAIK все еще публикуется. Так что, если вы действительно отчаянны, вы можете написать свои собственные обертки вокруг таких вещей, как FileInputStream и FileReader и т. Д. Я считаю, что в дереве файлов JRE есть имя каталога, в которое вы можете поместить Jars "беспорядочных" классов; это называется "одобрено" или что-то в этом роде. Это, или вы могли бы вносить изменения исходного кода в код библиотеки JRE и создавать свои собственные jar-файлы замены для библиотек Sun (или любых других). Это явно не чисто или очень переносимо. У меня нет собственного опыта с такими мерами, и я бы не рекомендовал их.