Вопрос: Остался последний вопрос, который задан в упражнении: Зачем понадобилось создавать объект « monitor»?

Ответ: Я не буду вас пытать. Я нарисую.

Представьте у вас есть класс. Большой! Сложный! Это что значит? Это значит у него внутри членов классов полно! А теперь представьте, что вы начнете писать код синхронизации. Этим объектом начнут пользоваться люди, а еще коллеги ваши. И кто-то будет кричать «давай я на этом буду ставить синхронизацию!», а другой «я на этом!». Полный бардак! Проходной двор короче.

Поэтому существует такой интересный подход. В большом сложном классе, где много полей и непонятно каким пользоваться для синхронизации мы создаем одно специальное поле и только им во всех сценариях искусственно пользуемся. Просто искусственно добавляем еще один объект. Мы говорим, не надо, а вдруг вы там поменяете бизнес-логику, добавите что-то или удалите. Еще потом синхронизацию из-за этого переделывать. Да вы что? Поэтому мы берем своими руками и говорим «Нет, мы сами сделаем объект. Маленький, чтобы память поэкономить. Какого там он типа? Object. Этого достаточно, потому что в Objectи есть поле, которое, собственно говоря, synchronizedвключает и выключает». Именно там. Оно у нас там приватное или нет? Да, ну мы внутри класса находимся. А представьте себе, если это будет например происходить извне. Кто-то извне должен управлять синхронизацией. Мы тогда сделаем специальный гетер, который будет возвращать этот объект для синхронизации. И ему каждый раз когда надо будет писать synchronized, он пишет какой-то объект.get(); Например, Microsoftназвал это свойство SyncRoot – главный корневой объект для синхронизации. Я здесь в лабораторной взял слово «monitor». Потому что в Objectмонитор синхронизации. Как-то это созвучно, но важно, что это будет один специально предназначенный только для этого. Его никто не уберет из-за того что изменились требования. И каждый кто будет выполнять синхронизацию будет делать только на этом одном объекте, тем самым защищая вот это все. Это как семафор раньше называлось.

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

Вопрос: Гигантская библиотека классов Java. Там пишут потокобезопасные классы специально? Я бы сказал, что нет. Они пару раз ошиблись, потом перестали писать. Идеология такая, что у вас в библиотеке никто специально не разрабатывает потокобезопасные классы. Представьте, как бы было странно. Они пишут какой-то класс и говорят «О! А давайте мы сделаем людям добро! Сделаем им потокобезопасный код! И начинают там заворачивать гайки.». А вы пишете обычную однопотоковую программу. Ну зачем?! Ну возьмите этот классический пример – коллекции. Они же их сделали потокобезопасными, а потом сказали deprecated. Почему!? Кому это надо? Я пишу обычную программу. Зачем мне ваш навороченный вектор? У меня однопотоковая программа. Поэтому классика говорит, если он у тебя неизменяемый, то в подарок получи потокобезопасный класс. Это сделано неспециально. Во всех остальных случаях мы пишем обычный класс, а вы в своей навороченной системе говорите вот мне здесь нужна потокобезопасность. Вот и выкручивайтесь. Ну понятно, что прошло столько лет, а именно 20 (на момент написания данной лекции), и в какой-то момент они сказали: «ну хорошо, мы видим, как люди выкручиваются и ничего у них не выходит». Такую лажу пишут, как-будто первый раз на Javaсели программировать. Давайте мы сделаем пару классов со встроенной синхронизацией, дабы помочь людям. Сделали классы для работы с данными. Появились новые потокобезопасные коллекции. Но это по доброте душевной. А так не пишут потокобезопасные классы. Не правильно это.

Группы потоков

Ну я бы не сказал, что это deprecated, но это очень старинная вещь, которая называется группы потоков. Представьте, что вы создали 100 потоков. Потом прошло 5 минут. И вы хотите узнать, а сколько из них еще живых, а кто завершился. Писать свой контейнер-менеджер, который будет все потоки запоминать, потом будет смотреть кто там еще isAlive? Не нужно этого делать. Почему? А вот, есть такой класс. Называется он ThreadGroup. Старинный. Где он находится? В java.langкаком-нибудь. Но и потоки лежат в java.lang. Посмотрите на версию! 1.0. Поэтому они бы написали здесь, чем еще надо пользоваться, но видите, нету вариантов посмотри еще. Поэтому на сегодняшний день вряд ли бы мы стали этим пользоваться. Но и писать такое тоже не нужно. Уже все есть. Для общего развития нужно знать. Есть более современные методы, но их рассмотрим позже.

Итак! Вы создаете поток, и обратите внимание, там есть хитрый конструктор, у которого первый идет «группа – gr». Вот здесь после вызовов startпрошло много времени. Мы обращаемся к этому «gr» и говорим «а дай еще живых потоков!». Видите какой хороший метод activeCount?Он опросил всех и сказал, что их 5 штук. Мы создали массив из 5 элементов, а потом с его (gr) помощью туда загрузили ссылки на потоки, которые еще выполняются. Вот так можно регулировать. Что-то мы с ними пообщались, а потом вызвали interrupt. Причем обратите внимание, что на контейнере. А он уже interruptразошлет всем тем, которые там не хотят завершаться. Ну так… Простенькое управление.