在并发的世界里，选择合适的状态处理方法将对并发性和正确性起到决定性的影响。这方面可选的方法有：共享可变性、隔离可变性以及完全不可变性。
对于并发问题来说最好的解决方法是从根本上消灭它而不是花很多时间解决它。要做到这一点其实很简单，只要消除可变状态就可以了，即我们要围绕不可变性或至少是隔离可变性来设计应用程序。
下面是两种较新的基于JVM虚拟机开发语言Clojure，Scala，Groovy等的解决方案
1.软件事务内存STM（Software Transaction Memory）
STM是针对共享可变性问题的一次大胆尝试，其核心思路是将可变实体从不可变状态值中分离出来。STM是经由Clojure成功实践之后才逐渐流行起来的。在Clojure语言中，状态是不可变的，而托管实体仅在STM的事务控制范围是可变的。这种做法不仅可以使可变实体的行为具备可预测性和确定性，同时还提供了一种显式的锁无关的编程方法。
然而STM存在两个主要缺陷。其一，如果项目所使用的编程语言不是Clojure，那么必须格外小心，以确保锁处理的状态除了托管实体都是不可变的，而这一问题对于JVM上的绝大多数语言都同样存在。其二，必须确保事务的实现代码都是幂等的且无任何副作用。
也正是由于这个原因，STM更适用于写冲突不频繁的应用场景。因为在冲突不频繁的情况下自动重做的策略是OK的，而在某些极端情况下该策略可能会导致严重的性能问题。总而言之，只要我们能够小心谨慎地处理托管的共享可变性，STM也能够实现理想的并发度。但是在没有底层语言支持的情况下，我们要达到这一目标的代价会比用Clojure实现大很多。
2.基于角色的模型
通过将隔离可变性的思想发扬光大，该模型从根本上消除了同步问题。其主要特点为：每个角色均各自独立运行，相互之间依靠高效的异步消息进行通信，并保证同时到达的消息通过排队的方式逐个处理。
该模型的主要问题是，包括读操作在内的并发任务之间的所有通信都是通过消息来完成的。所以那些需要获得完全一致的状态值的读操作就不得不交叉地发送请求以相互印证。使用多角色协作来设计应用程序的方法与设计一个OO应用程序的方法是有很大区别的。
在基于角色的模型中，不但要确保消息是不可变的，并且为了使其能够独立完成关键任务，对角色的定义也都是相当的粗粒度的。此外，应当注意不要将角色们之间的交互设计得过于繁复，以避免角色们都将时间消费在相互等待上而无法处理手头堆积的问题。
总而言之，选择并发模型并未将我们强行捆绑到特定的语言上。模型的选择是由应用程序的特性、我们使用的设计方法以及团队进行自我调整以适应新模型的意愿共同决定的。