The previous lesson ended on a warning: when multiple threads read and write the same mutable data without coordination, the result depends on unpredictable timing, producing race conditions. This lesson is about the tools Java provides to make shared mutable state safe. The most fundamental is the synchronized keyword, which gives a thread exclusive access to a block of code or an object's monitor, so only one thread can be inside at a time.
Beyond synchronized, Java offers explicit Lock objects (notably ReentrantLock) for more flexible locking, the volatile keyword for guaranteeing visibility of a field's latest value across threads, atomic classes (like AtomicInteger) for lock-free single-variable updates, and a family of concurrent collections (ConcurrentHashMap, CopyOnWriteArrayList) designed for safe concurrent access. Each addresses a different facet of the two core concurrency hazards: mutual exclusion and memory visibility.
Understanding synchronization matters because correct concurrent programs require it and incorrect ones fail in subtle, intermittent ways, and because the wrong amount of it causes its own problems: too little gives races, too much gives contention and deadlock. Knowing when to use synchronized, when an atomic or concurrent collection is simpler and faster, and what visibility and atomicity actually guarantee is essential to writing concurrent code that is both correct and performant.