Комментарии 9
используйте lock object, если есть хотя бы потенциальная возможность что на объекты вашего класса будет синхронизоваться кто-то кроме Вас
Не знаю как с Явой, но относительно C# этот момент обсасывается каждый раз, когда речь заходит о том, на что лочить — не встречал книжки, где бы это не упоминалось.
Даже если бы в самом коде Thread ничего подобного не было, использовать notify на публично доступном объекте (а с учётом Thread.currentThread() и Thread.enumerate() очень широко доступном) — не лучшая затея.
НЛО прилетело и опубликовало эту надпись здесь
Ну это как раз нормальный паттерн — вместо конструктора с Runnable переопределять run() в самом треде.
Часто при таком использовании код становится компактнее.
Часто при таком использовании код становится компактнее.
НЛО прилетело и опубликовало эту надпись здесь
Однако в официальной же документации указано:
There are two ways to create a new thread of execution. One is to declare a class to be a subclass of Thread. This subclass should override the run method of class Thread. An instance of the subclass can then be allocated and started.<...>Нигде не написано, что такой способ устарел или его следует избегать. Ну и по факту конкретно с тредами особой разницы нет (ну если не заниматься извратом, описанным автором — использовать wait/notify для объекта, который полностью не контролируешь). А Composition over Inheritance — это не принцип, а техника. Её можно использовать или нет, но «нарушить» нельзя. Техника хорошая, но нужна не повсеместно.
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Пятничная история про synchronized-методы в классе Thread