Why do I need STM if I already have locks or AtomicReferences?

Look, if you're just updating a single counter, an AtomicInteger is perfect. It's fast and simple. But the moment you need to update two different things together—like moving money from a savings account to a checking account—locks become a nightmare. You have to decide the order in which you acquire locks to avoid deadlocks. If Thread A locks Account 1 then 2, and Thread B locks Account 2 then 1, you've just frozen your application.

Software Transactional Memory (STM) treats your memory like a database. Instead of manually locking resources, you wrap a group of operations in a transaction. Either everything inside the block happens, or none of it does. You don't worry about lock ordering because the STM system manages the consistency for you. It's the difference between manually managing a complex set of mutexes and just saying, "Make this whole block atomic."

How does the "transaction" actually work without locking everything?

STM usually uses optimistic concurrency control. Instead of locking the variable the moment you touch it, the system keeps a private log of all the reads and writes you're doing during the transaction. It's essentially a "draft" of your changes.

When you hit the end of the block, the system performs a "commit." It checks if any of the variables you read were changed by another thread while you were working. If nothing changed, it applies your draft to the real memory in one quick move. If something did change, the transaction is discarded and automatically retried from the start with the new values.

// Conceptual Scala STM (similar to ZIO STM or Clojure)
val accountA = TVar(100) // Transactional Variable
val accountB = TVar(50)

stm.atomically {
  val balanceA = accountA.get()
  if (balanceA >= 20) {
    accountA.set(balanceA - 20)
    val balanceB = accountB.get()
    accountB.set(balanceB + 20)
  }
}

In the example above, the system doesn't lock accountA and accountB immediately. It records "I read A as 100, and I want to change it to 80." If another thread sneaks in and changes account A to 90 before this block finishes, the commit fails, and the whole block runs again.

What happens when transactions constantly clash?

This is the trade-off. If you have a "hot spot"—a single variable that every single thread is trying to update simultaneously—STM can actually perform worse than locks. This is called livelock or contention. Your threads spend all their time retrying their transactions because the world keeps changing under their feet.

I've seen this happen in high-frequency trading simulations where everyone is fighting over a single global order book. The fix is usually to partition your data. Instead of one giant "World State" variable, you break it into smaller, independent TVars. The more granular your transactional variables are, the less likely two transactions will collide, and the more "optimism" the system can actually get away with.

📋 Practical Task

Implement an Atomic Warehouse Inventory Transfer

You are tasked with building a simplified inventory management system for a logistics company. You need to ensure that moving items between two warehouses is atomic—it's unacceptable for items to "disappear" or be "duplicated" if a crash or race condition occurs during the transfer.

Using a conceptual STM approach (or a library like ZIO STM if you have it configured), implement a transferStock function with the following requirements:

• Create a Warehouse class that holds a TVar[Int] representing the current stock level.
• The transferStock function must take a source warehouse, a destination warehouse, and an amount.
• The transfer must only occur if the source warehouse has enough stock.
• The entire operation (checking balance, subtracting from source, adding to destination) must be wrapped in a single atomic transaction.
• Test your implementation by launching 10 concurrent coroutines/threads attempting to move different amounts of stock between three different warehouses. Verify that the total sum of items across all warehouses remains constant regardless of how many transfers occur.