Синхронизированный доступ к ресурсу

Question

Предположим, у нас есть некоторый ресурс (файл на диске), в который мы должны записать байты, созданные разными потоками.Эти потоки порождаются каким-то процессом, который прослушивает некоторые события и порождает поток каждый раз, когда происходит событие.Поскольку у нас есть только один ресурс, мы должны синхронизировать методы класса, который выполняет операцию записи:

    synchronized void write(byte [] bytes) {
       //write data to file
    }

или создать некоторый мьютекс:

Object mutex = new Object();
void write(byte [] bytes) {
   synchronized(mutex) {
      //write data to file
   }
}

А теперь предположим, что у нас оченьстарый жесткий диск, поэтому он выполняет операцию записи слишком медленно.И несколько раз в день у нас происходило очень большое количество событий.Так что потоки сделают что-то вроде очереди на ресурс.Поэтому у меня есть следующие вопросы:

1. Сколько может быть такая очередь?
2. Если есть несколько потоков, ожидающих ресурс, и ресурс освободил, какой поток будет первым заниматьресурс.Будет ли это принцип FIFO?
3. Как изменится ситуация, если потоки имеют разные приоритеты?
4. Если ресурс - это объект DataSource, который создает Connection объект, участвующий в пуле соединений, будет ли онбыть таким же, как с файлом выше?

Answer 1

1. Длина очереди - это количество заблокированных потоков.Если вы продолжаете создавать потоки и все они блокируются в письменном виде, вы быстро поставите систему на колени.Вам, безусловно, следует использовать пул потоков, повторно использовать потоки вместо их создания и блокировать, когда в очереди слишком много событий.См. Executors.
2. Нет, это не FIFO.Порядок не определен.Вы можете использовать справедливую ReentrantLock, если вы хотите FIFO.Но это занимает больше времени, чем базовая синхронизация или несправедливая блокировка.
3. Зависит от платформы и не имеет детерминированного поведения.
4. Все зависит от реализации источника данных.Он может использовать честный алгоритм или просто использовать честную блокировку.Или это могло бы просто использовать синхронизацию и не быть справедливым.Вам нужно прочитать документ источника данных, если он достаточно подробный.

Answer 2

Из моего ограниченного понимания:

1 - Он может быть довольно большим, ограниченным количеством потоков, которые может иметь система (я думаю, что он ограничен максимальным количеством потоков или ограничением некоторых собственных ресурсов ОС). Я видел 100+.

2 - Да, потоки должны получать ресурс в режиме FIFO.

3- Нет, потоки с более высоким приоритетом могли бы встать в очередь раньше, но после того, как они в очереди, их место исправлено.

4 - Источник данных может быть другим, в основном это зависит от реализации пула. Я думаю, что Apache dbcp (как видно из Tomcat) ведет себя так, за исключением того, что существуют тайм-ауты, которые могут быть запущены, если пул не может назначить соединение в установленное время.

Надеюсь, это поможет.

Answer 3

1. Нет теоретического ограничения на количество ожидающих потоков с этим дизайном.
2. Непредсказуемо.Подразумеваемая спецификация java не требует упорядочения потоков для этого типа простой блокировки.Фактический порядок будет зависеть от реализации JVM и архитектуры узла, но вы никогда не должны зависеть от этого.
3. Это зависит от механизма потоков и может иметь или не иметь никакого эффекта.Однако механизм потоков JVM попытается запланировать поток с более высоким приоритетом перед более низким и фактически выгрузит потоки с более низким приоритетом, которые уже запущены.
4. Что касается ваших потоков, то оба они абсолютно одинаковы.Потоки зависят от механизмов синхронизации для управления использованием ресурсов, точный ресурс не должен изменять их поведение, кроме, возможно, более длительного времени ожидания, если соединение медленнее, чем файл.