Пятничная история про synchronized-методы в классе Thread

[@aush]

используйте lock object, если есть хотя бы потенциальная возможность что на объекты вашего класса будет синхронизоваться кто-то кроме Вас

Не знаю как с Явой, но относительно C# этот момент обсасывается каждый раз, когда речь заходит о том, на что лочить — не встречал книжки, где бы это не упоминалось.

[@novoselov]

Уточню в C# просто создается объект внутри класса для лока.

[@romik]

Даже если бы в самом коде Thread ничего подобного не было, использовать notify на публично доступном объекте (а с учётом Thread.currentThread() и Thread.enumerate() очень широко доступном) — не лучшая затея.

[@andll]

Я же не говорю что я вчера узнал про lock object. Но абстрактная теория это одно, а тут просто наглядная иллюстрация что бывает.
Подозреваю что с практической точки зрения мало кто ожидал бы что в небольшой программе из 100 строк кто-то будет синхронизоваться на Thread

[@andll]

Ну это как раз нормальный паттерн — вместо конструктора с Runnable переопределять run() в самом треде.
Часто при таком использовании код становится компактнее.

[@tagir_valeev]

Однако в официальной же документации указано:

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 — это не принцип, а техника. Её можно использовать или нет, но «нарушить» нельзя. Техника хорошая, но нужна не повсеместно.