Перемещение файлов после неудачной проверки (Java)

Попробуйте создать FileInputStream и передать его в StreamSource, а затем закрыть FileInputStream, когда закончите. Передав File, вы потеряли контроль над тем, как и когда закрывать дескриптор файла.

Когда вы устанавливаете sc = null, вы указываете сборщику мусора, что файл StreamSource больше не используется и что его можно собрать. Потоки закрываются в своем методе destroy(), поэтому, если они собираются сборщиком мусора, они будут закрыты и, следовательно, могут быть перемещены в системе Windows (у вас не будет этой проблемы в системе Unix).

Чтобы решить проблему, не вызывая GC вручную, просто вызовите sc.getInputStream().close() перед sc = null. В любом случае это хорошая практика.

Распространенным шаблоном является создание блока try .. finally вокруг любого использования дескриптора файла, например.

try {
    sc = new StreamSource(xmlFile);
    // check stuff
} finally {
    sc.getInputStream().close();
}
// move to the appropriate place

В Java 7 вы можете вместо этого использовать новый попробуйте с блоком ресурсов.

Попробуйте sc.getInputStream().close() в улове

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

Тем не менее, я уже видел, как это происходит под окнами, по крайней мере, три года: даже если вы закроете поток, действительно каждый поток, если вы попытаетесь переместить или удалить файл, он вызовет исключение ... если только ... вы явно вызываете System.gc().

Однако, поскольку System.gc() не является обязательным для JVM для фактического выполнения цикла сборки мусора, и поскольку даже если это была JVM, она не обязана удалять все возможные объекты мусора, у вас нет реального способа убедиться, что файл можно удалить "сейчас".

У меня нет четкого объяснения, я могу только представить, что, вероятно, реализация java.io для Windows каким-то образом кэширует дескриптор файла и не закрывает его, пока дескриптор не будет собран мусором.

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

Решение, которое я использовал в прошлом, но которое довольно хакерское, заключалось в следующем:

1. Поместите файлы для удаления в «список»
2. Пусть фоновый поток периодически проверяет этот список, вызывает System.gc и пытается удалить эти файлы.
3. Удалите из списка те файлы, которые успели удалить, и оставьте там те, которые еще не готовы.

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

Может быть хорошей идеей также вызывать deleteOnExit для этих файлов, чтобы, если JVM завершит работу до того, как ваш поток завершит очистку некоторых файлов, JVM попытается их удалить. Однако в то время у deleteOnExit была собственная ошибка, препятствовавшая именно удалению файла, поэтому я этого не делал. Может быть, сегодня это решено, и вы можете доверять deleteOnExit.

Это ошибка JRE, которую я нахожу самой раздражающей и глупой, и я не могу поверить, что она все еще существует, но, к сожалению, я столкнулся с ней всего месяц назад в Windows Vista с последней установленной JRE.

Довольно старый, но некоторые люди все еще могут найти этот вопрос.

1. Я использовал Oracle Java 1.8.0_77.
2. Проблема возникает в Windows, а не в Linux.
3. Создается впечатление, что экземпляр StreamSource с File автоматически выделяет и освобождает файловый ресурс при обработке валидатором или преобразователем. (getInputStream() возвращает null)
4. В Windows перемещение файла на место исходного файла (удаление исходного файла) после обработки невозможно.

Решение/обходной путь: переместите файл, используя

Files.move(from.toPath(), to.toPath(), REPLACE_EXISTING, ATOMIC_MOVE);

Использование ATOMIC_MOVE здесь является критическим моментом. Какой бы ни была причина, она как-то связана с раздражающим поведением блокировки файлов Windows.