FileOutStream.write (byte []) всегда блокируется? - PullRequest
1 голос
/ 17 марта 2011

Мне было интересно, всегда ли FileOutputStream.write (byte []) блокирует текущий поток, что приводит к переключению ThreadContext, или же эта операция не блокируется, если достаточно много буферов ОС для обработки байтов.

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

Нет, я не профилировал его, это скорееконцептуальные мысли.

Ответы [ 4 ]

5 голосов
/ 17 марта 2011

Не нужно быть.

FileOutputStream.write (byte []) является нативным методом. Здравый смысл подсказывает, что write () может просто записывать во внутренние буферы, и более поздний вызов flush () фактически подтвердит это.

4 голосов
/ 17 марта 2011

Вы можете использовать log4j org.apache.log4j.AsyncAppender, и запись вызовов не будет блокироваться.Фактическая регистрация ведется в другом потоке, поэтому вам не нужно беспокоиться о том, что вызовы log4j не будут возвращаться своевременно.

3 голосов
/ 17 марта 2011

По умолчанию immediateFlush включено, что означает, что регистрация ведется медленнее, но гарантирует, что каждый запрос на добавление фактически записывается. Вы можете установить значение false, если вам все равно, будут ли записаны последние строки в случае сбоя приложения.

log4j.appender.R.ImmediateFlush=false

Кроме того, взгляните на этот пост на Log4j: Советы по повышению производительности , в котором автор получил некоторые статистические данные об использовании immediateFlush, bufferedIO и asyncAppender. Он заключает, что для локального ведения журнала «установите immediateFlush=false и оставьте bufferedIO по умолчанию без буфера» и что «asycAppender на самом деле занимает больше времени, чем обычный не-асик».

1 голос
/ 17 марта 2011

Скорее всего, это будет зависеть от ОС, драйверов и базовой файловой системы. Например, если включено кэширование записи, оно, скорее всего, сразу же вернется. Я видел гигабайты / сутки журналов, записанных синхронно, не слишком сильно влияющих на производительность, если IO не является узким местом. Вероятно, все же стоит написать их асинхронно, если вас беспокоит время отклика. И это устраняет потенциальные будущие проблемы, например, если вы переключились на запись на сетевой диск и в сети возникли проблемы.

...