知识库--STM内存事务简介（118）

Shared mutable variables had to synchronize. Instead of relaxing and enjoying that feeling of a job well done, you probably had a nagging feeling of doubt, wondering whether you managed to synchronize in all the right places. My programming has involved quite a few such unnerving(不安) moments. That is mostly because of shared mutable state in Java failing the principle of least surprises. If we forget to synchronize, then unpredictable and potentially catastrophic results await us. But, to err is human; to forget is our nature. Rather than punish us, the tools we rely on should compensate for our deficiencies and help reach the targets our creative minds seek. For predictable behavior and results, we need to look beyond the JDK.

In this chapter, we’ll learn how to play it safe with shared mutability using the STM(Software Transactional Memory) model popularized by Clojure. Where possible, we can switch to or mix in Clojure on projects. But we are not forced to use Clojure, because there are ways to use STM directly in Java, thanks to nice tools like Multiverse(https://blenderartists.org/forum/showthread.php?109649-Blender-to-Multiverse-Export-Tool) and Akka(http://doc.akka.io/docs/akka/2.0/intro/getting-started-first-java.html). How to program transactional memory in Java. This model of programming is quite suitable when we have frequent reads and very infrequent write collisions(冲突)–it is simple to use yet gives predictable results.

learning:
1 Synchronization Damns Concurrency
2 The Deficiency of the Object Model(对象模型的缺陷)
3 Separation of Identity and State
4 Software Transactional Memory(STM)
5 Transactions in STM
6 Concurrency Using STM
7 Concurrency Using Akka/Multiverse STM
8 Creating Transactions
9 Creating Nested Transactions
10 Configuring Akka Transactions
11 Blocking Transactions – Sensible Wait
12 Commit and Rollback Events
13 Collections and Transactions
14 Dealing with the Write Skew Anomaly
15 Limitations of STM