А теперь я вам расскажу про производительность этого класса. Готовы?

Производительность будет следующая. Представьте себе рынок. Внутри рынка 30 палат. Вокруг рынка ОМОН. И запускают на рынок по одному покупателю. Он зашел к одной из этих 30 палат. Подошел, купил, вышел. ОМОН убедился, что он вышел. Следующий. Рынок просто обалденный! И у вас будет такая программа. Главное очередь пораньше занять!

Вы спросите «И?». А нет тут ответа. Думайте над архитектурой. synchronized должно быть минимум. В умных книжках, на курсах обычно пишут по-английски «avoidsynchronizationifpossible».

По поводу многопоточности:

Как я уже сказал, на клиенте вы только будете использовать для того, чтобы не было блокировки. А на сервере вы вообще не имеете права создавать потоки.

По поводу синхронизации:

А синхронизации желательно, чтобы ее вообще практически не было.

Взаимодействие потоков

Слово «synchronized» конечно красивое, но это не все, что у нас есть. Если бы библиотеки ограничились бы одним этим словом, то было бы просто «замечательно». Но для нас сделали много чего другого.

Вспомните «obj.»! Какие там методы? notify(), wait(). Я их отказывался комментировать в прошлом курсе. Сказал, рано еще. А вот теперь пришла пора.

Ситуация выглядит так. Допустим, у меня есть три потока.

· Допустим первый поток получает данные.

· Второй поток их обрабатывает.

· Третий поток эти данные куда-то отправляет на экран.

Ну а данные-то в каком-то объекте лежат, т.е. у меня есть один объект к которому по очереди должны обращаться три потока. Причем каждый поток у него написано, что он делает. Объект есть. Три потока есть. Я их буду стартовать естественно по уму. Вначале стартую первый, потом второй, потом третий. Кто из них первый к объекту придет? Неизвестно. Ничего не делая, порядка мы не получим. У нас всегда будет бардак. У нас никогда не будет 1, 2, 3. А если нам повторно нужно 1, 2, 3? Это будет в любом порядке. И если мне нужно гарантировать очередность доступа к объекту моих потоков (1,2,3 и только так), то мне нужны методы notify() и wait().

Давайте не спеша разбираться. Эти методы можно вызывать только внутри synchronized, иначе будет исключение!

В прошлом курсе мы даже не могли написать notify() потому что надо было написать synchronized, и все. Дальше я был бессилен.

Здесь внутри этих методов по одной строчке. Поэтому synchronized написали сверху, чтобы было попроще.

Кстати, по поводу synchronized забыл сказать вот еще что! Когда мы пишем его внутри, то это не весь метод защищен от одновременного доступа, а если вы напишете внутри на две строчки, то только эти две строчки будут защищены от одновременного доступа. И получается, что если один поток зашел, второй поток зашел, то это не значит, что они одновременно придут к слову synchronized, а время когда будут ждать, если вы защитили 2 строчки и весь метод, то оно разное. Чем меньше строк кода внутрь synchronized попало, тем вероятность блокировок остальных потоков уменьшается.

Итак, давайте по этому слайду, я сделаю понятный рисунок.

Класс Test – это объект. Методы – это члены данного класса. Значит на объекте этого класса есть this. Первый поток у нас пришел и он прорвался сюда допустим в какой-то метод, а значит здесь будет поставлена галочка «Занято!». И вот он начал выполнять некий код. Выполняется какая-то проверка. Технические детали не важны. Но он видит, что он вне очереди, т.к. он обогнал своих «коллег». Он должен, например, считать статистику, а данные еще не получены. Но выйти сейчас из этого блока synchronized обидно будет. Ты уже попал туда. Ты уже зашел. А потом снова очередь должен будешь отстоять. Поэтому есть такая хитрая возможность вызвать wait. Вот этот первый поток в этом вызове wait() будет заблокирован здесь, но он не покидает раздел synchronized, но он внутри переходит в состояние ожидания. А перейдя в состояние ожидания, он дает возможность другому потоку зайти в этот же раздел synchronized. Т.е. он как бы говорит «я встану и подожду у стеночки и ничего не буду делать». Получается, что сюда может прийти еще один поток и объект свободен, потому что тот (первый поток) хоть и не совсем покинул блок, но доступ он добровольно передал. Далее заходит другой поток, проверяет его очередь или нет. И тоже может оказаться, что не его. И тогда он тоже вызывает wait. И будет второй поток, который будет ждать у стеночки. Зашел третий поток. Да, это его очередь. Он получил данные, и если он сейчас покинет этот раздел synchronized и никаких больше других средств подсказать тем «ребятам», что можно начинать действовать нету, то они там так и останутся ждать у стеночки (неизвестно чего). Поэтому в этом примере кода кто-то извне пинает. У нас есть некий менеджер, который извне говорит «Ты жди!», «Ты работай!». А здесь в обычной системе этот notifyдолжен вызываться последний, т.к. это выглядит естественнее. Выполнив все свои задачи, поток который покидает раздел synchronized говорит «Все! Можете продолжать работать!». Notifyон говорит одному, а notifyall– всем. Если вы точно знаете, что тот, кто ждет, он один, то notifyдостаточно, а если надо многих пробудить от ожидания, то как раз notifyall–это единственный способ. И тогда эти двое снова попытаются с этим объектом работать, но кому-то повезет, а кому-то нет. Но потом будет снова notifyи снова тот последний, который там остался опять же будет предложено продолжить работу. И он всё отработает.

И обратите внимание, что писать нужно не if, а while. Потому что если поток распознав, что это не его очередь и перешел в ожидание, а потом кто-то сказал notifyAllи его не вовремя пробудил от ожиданий, он же возвращается в начало цикла и снова проверяет, а это не моя очередь. его снова пробуждают, а он говорит – это не моя очередь. А if он однократно работает.