Вопрос: Почему они пишут по одному, а читают вместе?

Ответ: Потому что это такой класс.

Обратите внимание, что повторное чтение всех пятерок

Здесь все читают одновременно, но потом каждый из пяти говорит «Хочу менять!», но так как в этот момент еще кто-то другой читает, то их блокируют. И получается, что пока все пять, которые одновременно начали читать и пока они не завершат все читать, у нас писателей не запускают. Но писатель накапливаются. И когда последний читатель завершается, только после этого можно начать запись изменения данных. Но как раз пятый закончил и он сказал «Тоже хочу менять». И получается, что все пятеро накопились и все начинают менять друг за другом, но пятеро. И кто первый допустим из них изменил данные, он скажет «хочу читать». Емускажут «нуичто?». У нас есть список, который меняют. Вот пока он не закончится «Жди!». И получается, что они впятером вместе начинают читать. Понимаете, что паттерн «Читатели» - много, а «Писатель» - один. И вот эта реализация не является «эталоном». Опять же, может быть у вас другая бизнес-логика. Может быть вы скажете «Мне нужно, чтобы у меня было много писателей и один читатель». Ну напишете сами.

Вопрос: readLock мы ставим только для того чтобы «писатель» не начал в наше время писать?

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

Новые поток безопасные коллекции и классы (ThreadLocalRandom, AtomicInteger и др.)

Так… Хорошо… Еще что они для нас по доброте душевной сделали?

Где лежат наши данные? В коллекции. Я должен защищать данные? Могу и я. Но если это сделают они, то я скажу им спасибо. Поэтому в новой версии появились новые потокобезопасные коллекции. Не те которые Vectorи т.д., а новые. Причем они делятся на блокирующие и не блокирующие.

Blocking collections: This kind of collection includes operations to add and remove data. If the operation can't be made immediately, because the collection is full or empty, the thread that makes the call will be blocked until the operation can be made. Non-blocking collections: This kind of collection also includes operations to add and remove data. If the operation can't be made immediately, the operation returns a null value or throws an exception, but the thread that makes the call won't be blocked. Through the recipes of this chapter, you will learn how to use some Java collections that you can use in your concurrent applications. This includes: - Non-blocking lists, using the ConcurrentLinkedDeque class - Blocking lists, using the LinkedBlockingDeque class - Blocking lists to be used with producers and consumers of data, using the LinkedTransferQueue class - Blocking lists that order their elements by priority, with the PriorityBlockingQueue - Blocking lists with delayed elements, using the DelayQueue class - Non-blocking navigable maps, using the ConcurrentSkipListMap class

Т.е. мы имеем уже более профессиональный подход к написанию потокобезопасных коллекций.

Вопрос: Что означает «блокирующий»?

Ответ: Вы в названии коллекции видите название «Blocking», например, PriorityBlockingQueue или LinkedBlockingDeque, но не во всех. Представьте, я говорю: «добавь в коллекцию новый элемент!» или «удали элемент!», а там нет места куда добавлять. Ну закончилось, только можно ограничивать или удалять нечего, еще никто ничего не добавил. Так в случае блокирующей коллекции ваш поток будет блокирован и будет ждать, пока не появится место или пока элемент не появится, который вы собираетесь удалять. Это блокирующий вариант.

Вопрос: А неблокирующий?

Ответ: А неблокирующий он либо завершится возвратом null, либо exception в зависимости от функций, которые вы вызываете.

А что вам нужно? Никто не знает. Поэтому и сделали два набора. Смотрите. Думайте. Выбирайте.

Идем дальше…

Случайные числа вычисляются сегодня с помощью другого класса. Не вот этот random, а ThreadLocalRandom. Если вас спросят каким классом пользоваться? Если вас спросят просто коллеги, то можно просто ответить «каким хотите». А если вас спросят на экзамене по 1.7 версии Java, то отвечать надо однозначно, которая в этой версии вышла. Какая, короче говоря, тут идея? Почему это считается чуть лучше? Потому что это безопаснее. Он генерирует псевдослучайные числа и в одном потоке этой локальной памяти все это получается хранится. А тем самым предполагается, что никто туда не влезет. Вот написали генерацию псевдослучайных чисел для одного потока. Ну и ради бога.

По поводу атомарных операций:

Это действительно было бы не плохо, если бы в Javaбыли атомарные операции. Однако в Javaпридумали и написали атомарные классы, и назвали они их Atomic. На самом деле их можно прервать, но здесь важно другое. Важно, что все эти классы, находящиеся в целом packageсо словом Atomic, это значит, что вы можете увеличивать AtomicInteger, работать с AtomicInteger без синхронизации и без блокировок, но это будет потокобезопасный код. Вы скажете: «Как?». Я там целую научную статью видел на английском, где было доказано и показан алгоритм. Но алгоритм основан на следующем подходе. Мы делаем и сравниваем. Нам надо увеличить на 1. Мы говорим, что у нас «5» и мы увеличиваем на 1. Смотрим «больше 1? а! на два - лажа». Т.е. без блокировки, мы не блокируем данные. Мы примерно, как в варианте OptimisticReadingчитаем. Когда я что-то делаю, ничего не произойдет плохого, но потом я сравниваю и если произошло, то делается повторно и там в зависимости от разных методов. Кто-то ничего не будет делать повторно, а кто-то наоборот, пока не увеличится на единицу будет делать. Но алгоритм без блокировок, без синхронизации. Измени – сравни. Измени – сравни. И вот это и есть атомарные операции. Это целый packageconcurrent. И количество классов растет. Даже есть AtomicArray!

Когда я разбирался с этим, то я зашел на официальную часть Oracle, где были научные основы этого алгоритма.