Параллелизм, объектная видимость

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

public void run() {
    synchronize (this) {
        if (this.state != -1)
            this.state++;
    }
}

Вместо использования синхронизации вы также можете использовать AtomicInteger # getAndIncrement () (если раньше вам не понадобился if).

private AtomicInteger state = new AtomicInteger();

public void run() {
    state.getAndIncrement()
}

Ваш код, в частности этот бит

            if (this.state != -1)
                    this.state++;

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

Но ваш дизайн основан на утверждении, что всегда будет только один экземпляр Test, и , этот единственный экземпляр предоставляется только одному (тому же) потоку. (Но обратите внимание, что единственный экземпляр на самом деле является общим состоянием между основным потоком и потоком-исполнителем.)

Я думаю, вам нужно сделать эти предположения более явными (в коде, например, используйте ThreadLocal и ThreadLocal. получить()). Это сделано для защиты как от будущих ошибок (когда другой разработчик может по неосторожности нарушить предположения проекта), так и,

Если ваш ExecutorService является однопоточным, то общего состояния нет, поэтому я не понимаю, как здесь могут быть какие-то проблемы.

Однако не было бы больше смысла в передавать новый экземпляр вашего класса Test каждому вызову execute () ? т.е.

for (int i=0; i<10; ++i)
    ex.execute(new Test());

Таким образом, общего состояния не будет.

Изначально я думал так:

Если бы задача всегда выполнялась той же нити, не было бы проблема. Но Excecutor произведено newSingleThreadExecutor () может создавать новые потоки, чтобы заменить те, которые убиты по любой причине. Здесь нет гарантия о том, когда замена поток будет создан или какой поток создаст его.

Если поток выполняет некоторые записи, то вызывает start () в новом потоке, те записи будут видны новым нить. Но нет никакой гарантии, что это правило применимо и в данном случае.

Но неоспоримое право: создание правильного ExecutorService без достаточных барьеров для обеспечения видимости практически невозможно. Я забыл, что обнаружение смерти другого потока - это связь синхронизируется с . Механизм блокировки, используемый для простоя рабочих потоков, также потребует барьера.

Это нормально, чтобы состояние было энергонезависимым в этом конкретном коде, потому что существует только один поток, и только этот поток обращается к полю. Отключение кэширования значения этого поля в единственном потоке, который у вас есть, просто снизит производительность.

Однако, если вы хотите использовать значение состояния в основном потоке, который запускает цикл, вы должны сделать поле изменчивым :

    for (int i=0; i<10; ++i) {
            ex.execute(test);
            System.out.println(test.getState());
    }

Однако даже это может работать некорректно с volatile, потому что нет синхронизации между потоками.

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