Коротко — потому что операция $counter++$ не атомарна и есть проблемы видимости между потоками.
Почему так:
- $counter++$ фактически выполняется как три шага: чтение, вычисление, запись — например, $\text{read}v$, $\text{compute}v+1$, $\text{write}v+1$. При параллельном выполнении два потока могут оба прочитать одно и то же значение (скажем, $0$), оба записать $1$ — потерянное обновление: ожидаем $2$, получаем $1$.
- Без синхронизации изменения одного потока могут быть не сразу видны другому (Java Memory Model) — даже если операции не перекрываются, чтение может вернуть «старое» значение.
Как исправить (варианты, кратко):
1) Синхронизация:
- synchronized-блок:
Runnable r = () -> {
synchronized(lock) { counter++; }
};
- или synchronized-метод. Гарантирует атомарность и видимость.
2) Atomic-классы (рекомендуется для простого инкремента):
- Использовать AtomicInteger:
AtomicInteger counter = new AtomicInteger(0);
Runnable r = () -> counter.incrementAndGet();
- Это атомарно и быстрее, чем общая синхронизация при низкой/средней нагрузке.
3) ReentrantLock:
- Если нужен явный lock/unlock или tryLock:
lock.lock();
try { counter++; } finally { lock.unlock(); }
4) LongAdder для высокой конкуренции:
- LongAdder даёт лучший масштаб при большом числе потоков:
LongAdder counter = new LongAdder();
counter.increment();
long value = counter.sum();
Что не поможет:
- volatile int counter; — сделает видимым последнее значение, но не сделает $counter++$ атомарным (проблема потерянных обновлений останется).
Дополнение: чтобы корректно прочитать итог после старта потоков, дождитесь их завершения через t1.join(); t2.join(); — иначе можете читать значение до завершения инкрементов.