Подтвердить что ты не робот

Многопоточный доступ к файлу

У нас есть многопоточная java-программа. Несколько потоков будут записываться в файл, и один поток будет читать из этого файла. Я ищу некоторые дизайнерские идеи. Необходима ли синхронизация?

4b9b3361

Ответ 1

Я бы рассмотрел синхронизацию в этом случае. Представьте, что 2 потока (t1 и t2) одновременно открывают файл и начинают писать на него. Изменения, выполненные первым потоком, перезаписываются вторым потоком, потому что второй поток является последним, чтобы сохранить изменения в файле. Когда поток t1 записывает в файл, t2 должен ждать, пока t1 не закончит его задачу, прежде чем он сможет его открыть.

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

Ответ 2

FileChannel в теории потокобезопасен. Из javadoc:

Файловые каналы безопасны для использования несколькими параллельными потоками. метод close может быть вызван в любое время, как указано в канале интерфейс. Только одна операция, которая включает в себя позицию канала или может изменить размер своего файла, может быть в любой момент; попытки инициировать вторую такую ​​операцию, в то время как первая по-прежнему будет выполняться до тех пор, пока не завершится первая операция. Другие операции, в частности те, которые занимают явное положение, могут продолжаться одновременно; действительно ли они делают это, зависит от и поэтому не указывается.

Если вы можете использовать их, вы можете использовать встроенную синхронизацию, вместо того, чтобы писать свои собственные.

Ответ 3

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

Ответ 4

Если вам нужны несколько читателей и один писатель, вы бы искали Read Write Lock или Mutex Read Write.

Но вам нужны несколько авторов и один читатель. Откуда вы знаете, что эти авторы не будут перезаписывать данные друг друга? Они каким-то образом разделены?

Ответ 5

Как только несколько потоков доступа доступа к общим данным, необходимо синхронизация. Если несколько потоков записываются в один и тот же файл без какой-либо блокировки, тогда потенциально вы потеряете проблему с обновлением.

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

Ответ 6

Вам нужна синхронизация (блокировка), если у вас есть смесь читателей и писателей или писателей и писателей. Если у вас есть только читатели, вам не нужна синхронизация.

Вы не хотите, чтобы два процесса записывались в один и тот же файл или один процесс записывал файл, который читает другой.

Ответ 7

В этом случае необходима синхронизация. FileChannel полезен для предотвращения изменения файлов процессами вне JVM: не для приложений, которые включают в себя несколько потоков, записывающих в один файл. От (дальше) JavaDoc для FileChannel:

Блокировки файлов хранятся от имени всей виртуальной машины Java. Они есть не подходит для контроля доступа к файл несколькими потоками в пределах та же самая виртуальная машина.

См. этот пост для краткого обсуждения стратегий обмена файлами между потоками.