Очистка файлов блокировки (.lck) в Java 8

Похоже, что java 8 внесла изменения в то, как обрабатываются файлы блокировки, и это заставляет меня накапливать много файлов .lck.

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

Кто-нибудь смягчил это более изящным образом?

Подтверждено, что это ошибка по крайней мере в 8u25. Плохое поведение исчезает в Oracle 8u40 JRE.


java java-8 java.util.logging
person Sparkfizt    schedule 24.02.2015    source источник
comment
Не существует такого типа файлов, как файлы блокировки. .lck — это всего лишь расширение файла, вот и все. Что это за ОС? Как это связано с регистрацией?   -  person fge    schedule 25.02.2015
comment
Вы действительно имеете в виду log file?   -  person Zhedar    schedule 25.02.2015
comment
Файлы .lck используются API ведения журналов Java, чтобы показать, что файлы журналов в настоящее время используются процессом Java (по крайней мере, в Windows)   -  person Sparkfizt    schedule 25.02.2015

Ответы (1)


arrow_upward
2
arrow_downward

Это описано в разделе Является ли java.util.logging.FileHandler в Java 8 сломан?. Обновите JDK 8 до обновление 40 или новее который содержит исправление для JDK-8048020.

Вы должны ожидать увидеть файлы блокировки, когда FileHandler открыт. Если вы видите, что они задерживаются после выхода виртуальной машины, то это происходит из-за того, что FileHandler не был закрыт, виртуальная машина была остановлена ​​или аварийно завершила работу во время работы обработчика завершения работы, или произошло исключение ввода-вывода при попытке удалить их.

Платформа, на которой вы работаете, также играет роль при реализации FileLock, используемый FileHandler. Документация FileLock содержит следующее предупреждение:

Действительно ли блокировка предотвращает доступ другой программы к содержимому заблокированной области, зависит от системы и, следовательно, не указано. Собственные средства блокировки файлов в некоторых системах носят исключительно рекомендательный характер, а это означает, что программы должны совместно соблюдать известный протокол блокировки, чтобы гарантировать целостность данных. В других системах собственные блокировки файлов являются обязательными, а это означает, что если одна программа блокирует область файла, то другим программам фактически запрещается доступ к этой области таким образом, чтобы нарушить блокировку. В других системах то, являются ли собственные блокировки файлов рекомендательными или обязательными, настраивается отдельно для каждого файла. Чтобы обеспечить согласованное и правильное поведение на разных платформах, настоятельно рекомендуется использовать блокировки, предоставляемые этим API, как если бы они были рекомендательными блокировками.

Это означает, что FileHandler может иметь разное поведение блокировки на разных платформах.

С файлами блокировки также связана сборка мусора логгеров, которая не закроет прикрепленные обработчики. Эти проблемы рассматриваются в разделе JDK-8060132: Обработчики, настроенные на абстрактных узлах при ведении журнала .properties не всегда должным образом закрываются, и JDK-6274920: регистратор JDK держится надежно ссылка на экземпляры java.util.logging.Logger.

person jmehrens    schedule 25.02.2015
comment
Эта ссылка предполагает, что поведение увеличения блокировки - это изменение с 7 на 8. У меня нет проблем с истечением срока действия файлов блокировки при чистом завершении работы. Я проверю на u45 в четверг, чтобы увидеть, есть ли отличия. - person Sparkfizt; 25.02.2015
comment
Вы должны ожидать увидеть файлы блокировки, когда FileHandler открыт. Если вы видите, что они задерживаются после выхода виртуальной машины, то это происходит из-за того, что FileHandler не был закрыт, виртуальная машина была остановлена ​​или аварийно завершила работу во время работы обработчика завершения работы, или произошло исключение ввода-вывода при попытке удалить их. Правильно, это поведение, которое я ожидаю и вижу. Раньше в java 7 эти файлы блокировки использовались повторно, потому что виртуальная машина проверяла, остаются ли файлы открытыми. Теперь он никогда не будет повторно использовать файл блокировки, наличие блокировки заставляет его увеличиваться до следующего. - person Sparkfizt; 27.02.2015
comment
Это наблюдается на оракуле JRE 8u25. - person Sparkfizt; 27.02.2015
comment
Извините за все ответы, при дальнейшем тестировании может быть (что неудивительно) что-то с моей стороны. - person Sparkfizt; 27.02.2015