Почему следует блокировать this synchronized(this)?

мне была интересна сама запись. Почему здесь блокируется this, а this - это повар. Это вроде не я блокировал его, а уже было написано, или так надо было написать, чтобы задача валидацию прошла , не помню уже

Как блокировка по this помогает не создавать лишний объект?

Ну я думаю, что можно было в классе создать какое нибудь поле Object и использовать его мьютекс для синхронизированного блока

public class Cook implements Runnable {
    public boolean continueWorking = true;
    final Object obj = new Object;

    @Override
    public void run() {
        boolean needToWait;
        while (continueWorking || needToCookOrders()) {
            try {
                synchronized (obj) { // а можно взять прямо свой собственный мьютекс, т.е. синхронизироваться по this, кому как нравится ))
                    needToWait = !needToCookOrders();
                    if (!needToWait) {
                        cooking();
                    }
                }
....

Ваш ответ единственный в этой теме, где приведена информация по существу. Причем информация верная! Вы просто не совсем точно выразили свою мысль) Не понимаю почему другие участники накидали вам дизов. Остальные ответы либо не верны, либо запутывают еще больше. Если воспринимать задачу в том виде, в котором она поставляется для решения изначально (один повар), то synchronized(this) тут не нужен. В ресторане обычно поваров несколько. Доработать программу, чтобы было несколько поваров, тоже не трудно. Сделать можно двумя способами. Способ 1 - на основе существующего Runnable (чтобы затронуть synchronized(this)) Создаем новую нить на основе уже существующего Runnable-объекта + задаем нитям имена, чтобы выводить их в Cook.cook() и видеть работающего повара + закомментируем synchronized(this) в Cook.run():

Cook cookTarget = new Cook();
Thread cook1 = new Thread(cookTarget,"Повар1");
Thread cook2 = new Thread(cookTarget, "Повар2");

waiter.start();
cook1.start();
cook2.start();

Запускаем, программа вроде отработала и видно что суетились оба повара (за счет того, что мы добавили нитям имена и в Cook.cook() в нужных местах выводим название текущей нити). НО, в выдаче есть NullPointerException в Cook.cook() в строке:

Order order = manager.getOrderQueue().poll();      // повар берет заказ из очереди

О чем это говорит? Это говорит о том, что нити обоих поваров (напоминаю: synchronized(this) мы убрали) оказались в Cook.cook() и одна из них успешно извлекла заказ раньше другой. При этом заказ был единственный в списке. Вторая нить, которая также исполняет код в Cook.cook(), тоже пытается извлечь заказ и записывает в Order order значение null (ведь заказа уже нет). После чего эта же, вторая нить, пытается вызвать метод на объекте order (в котором null). Поэтому мы видим NullPointerException. Обработки этого исключения в коде нет, нить вышибает, она завершается. Дальше дорабатывает только одна нить (работает только один повар). Вывод: в ситуации когда заказы поступают реже, чем повара успевают их обработать, мы имеем логическую ошибку в коде программы (это конечно не race condition, все таки коллекции у нас потокобезопасны), но при аналогичном подходе, в коде другой программы, последствия могут быть печальными.new Cook(), Продолжаем экспериментировать. Уменьшаем время, которое официант тратит на обходы столов. В Waiter.run() изменяем Thread.sleep(100) на Thread.sleep(10). Зачем? Чтобы заказы поступали чаще и у поваров было больше работы, чтобы не получить NullPointerException как в случае выше. Запускаем и видим, что программа успешно работает. Оба повара суется. Ошибок нет. Теперь возвращаем код в исходное состояние: в Waiter.run() возвращаем Thread.sleep(100) и раскомментируем synchronized(this) в Cook.run() (двух поваров оставляем). Запускаем и видим, что программа нормально работает. Теперь повара попеременно готовят, занимая монитор cookTarget также попеременно. Кейс с NullPointerException не возникает. Другой вопрос что попеременная готовка в данном случае не выглядит эффективнее, чем если нить повара была одна, т.к. образуется bottle neck в виде метода сoock(). По идее, конечно, у каждого повара должна быть своя кухня и это уже способ 2.

2 способ - у каждого повара своя кухня (неявно, т.к. в программе нет объекта кухня, но он подразумевается в методе cook()):

Thread cook1 = new Thread(new Cook(),"Повар1");
Thread cook2 = new Thread(new Cook(), "Повар2");

Повара работают параллельно, не блокируя друг друга. synchronized(this) не нужен. Общий вывод: synchronized(this) в данной задаче нужен для ситуации когда поваров несколько "а кухня одна", чтобы не возникло логической ошибки в работе программы.

Уточните почему вы пишете, что занимается монитор cookTarget, ведь this это объект нити thread, и он передается в метод. Может ссылку какую на матчасть , не могу найти