在分布式环境中，处理并发问题就没办法通过操作系统和JVM的工具来解决，那么在分布式环境中，可以采取一下策略和方式来处理：

• 避免并发
• 时间戳
• 串行化
• 数据库
• 行锁
• 统一触发途径

避免并发

在分布式环境中，如果存在并发问题，那么很难通过技术去解决，或者解决的代价很大，所以我们首先要想想是不是可以通过某些策略和业务设计来避免并发。比如通过合理的时间调度，避开共享资源的存取冲突。另外，在并行任务设计上可以通过适当的策略，保证任务与任务之间不存在共享资源，比如在以前博文中提到的例子，我们需要用多线程或分布式集群来计算一堆客户的相关统计值，由于客户的统计值是共享数据，因此会有并发潜在可能。但从业务上我们可以分析出客户与客户之间 数据是不共享的，因此可以设计一个规则来保证一个客户的计算工作和数据访问只会被一个线程或一台工作机完成，而不是把一个客户的计算工作分配给多个线程去 完成。这种规则很容易设计，例如可以采用hash算法。

时间戳

分布式环境中并发是没法保证时序的，无论是通过远程接口的同步调用或异步消息，因此很容易造成某些对时序性有要求的业务在高并发时产生错误。比如系统A需要把某个值的变更同步到系统B，由于通知的时序问题会导致一个过期的值覆盖了有效值。对于这个问题，常用的办法就是采用时间戳的方式，每次系统A发送变更给系统B的时候需要带上一个能标示时序的时间戳，系统B接到通知后会拿时间戳与存在的时间戳比较，只有当通知的时间戳大于存在的时间戳，才做更新。这种方式比较简单，但关键在于调用方一般要保证时间戳的时序有效性。

串行化

有的时候可以通过串行化可能产生并发问题操作，牺牲性能和扩展性，来满足对数据一致性的要求。比如分布式消息系统就没法保证消息的有序性，但可以通过变分布式消息系统为单一系统就可以保证消息的有序性了。另外，当接收方没法处理调用有序性，可以通过一个队列先把调用信息缓存起来，然后再串行地处理这些调用。

数据库

分布式环境中的共享资源不能通过Java里同步方法或加锁来保证线程安全，但数据库是分布式各服务器的共享点，可以通过数据库的高可靠一致性机制来满足需求。比如，可以通过唯一性索引来解决并发过程中重复数据的生产或重复任务的执行；另外有些更新计算操作也尽量通过sql来完成，因为在程序段计算好后再去更新就有可能发生脏复写问题，但通过一条sql来完成计算和更新就可以通过数据库的锁机制来保证update操作的一致性。

行锁

有的事务比较复杂，无法通过一条sql解决问题，并且有存在并发问题，这时就需要通过行锁来解决，一般行锁可以通过以下方式来实现：

• 对于Oracle数据库，可以采用select ... for update方式。这种方式会有潜在的危险，就是如果没有commit就会造成这行数据被锁住，其他有涉及到这行数据的任务都会被挂起，应该谨慎使用
• 在表里添加一个标示锁的字段，每次操作前，先通过update这个锁字段来完成类似竞争锁的操作，操作完成后在update锁字段复位，标示已归还锁。这种方式比较安全，不好的地方在于这些update锁字段的操作就是额外的性能消耗

统一触发途径

当一个数据可能会被多个触发点或多个业务涉及到，就有并发问题产生的隐患，因此可以通过前期架构和业务设计，尽量统一触发途径，触发途径少了一是减少并发的可能，也有利于对于并发问题的分析和判断。

在写Java程序的时候，何时需要进行并发控制，关键在于判断这段程序或这个类是否是线程安全的。

当多个线程访问一个类时，如果不用考虑这些线程在运行时环境下的调度和交替执行，并且不需要额外的同步，这个类的行为仍然是正确的，那么称这个类是线程安全的。我们设计类就是要在有潜在并发问题存在情况下，设计线程安全的类。线程安全的类可以通过以下手段来满足：

• 不跨线程共享变量
• 使状态变量为不可变的
• 在任何访问状态变量的时候使用同步。
• 每个共享的可变变量都需要由唯一一个确定的锁保护。

满足线程安全的一些思路

1）从源头避免并发问题

很多开发者一想到有并发的可能就通过底层技术来解决问题，其实往往可以通过上层的架构设计和业务分析来避免并发场景。比如我们需要用多线程或分布式集群来计算一堆客户的相关统计值，由于客户的统计值是共享数据，因此会有并发潜在可能。但从业务上我们可以分析出客户与客户之间数据是不共享的，因此可以设计一个规则来保证一个客户的计算工作和数据访问只会被一个线程或一台工作机完成，而不是把一个客户的计算工作分配给多个线程去完成。这种规则很容易设计。当你从源头就避免了并发问题的可能，下面的工作就完全可以不用担心线程安全问题。

2）无状态就是线程安全

多线程编程或者分布式编程最忌讳有状态，一有状态就不但限制了其横向扩展能力，也是产生并发问题的起源。当你设计的类是无状态的，那么它永远都是线程安全的。因此在设计阶段需要考虑如何用无状态的类来满足你的业务需求

3）分清原子性操作和复合操作

所谓原子性，是说一个操作不会被其他线程打断，能保证其从开始到结束独享资源连续执行完这一操作。如果所有程序块都是原子性的，那么就不存在任何并发问题。而很多看上去像是原子性的操作正式并发问题高灾区。比如所熟知的计数器（count++）和check-then-act，这些都是很容易被忽视的，例如大家所常用的惰性初始化模式，以下代码就不是线程安全的：

这段代码具体问题在于没有认识到if(instance==null)和instance = new ExpensiveObject();是两条语句，放在一起就不是原子性的，就有可能当一个线程执行完if(instance==null)后会被中断，另一个线程也去执行if(instance==null)，这次两个线程都会执行后面的instance = new ExpensiveObject();这也是这个程序所不希望发生的。

虽然check-then-act从表面上看很简单，但却普遍存在与我们日常的开发中，特别是在数据库存取这一块。比如我们需要在数据库里存一个客户的统计值，当统计值不存在时初始化，当存在时就去更新。如果不把这组逻辑设计为原子性的就很有可能产生出两条这个客户的统计值。

在单机环境下处理这个问题还算容易，通过锁或者同步来把这组复合操作变为原子操作，但在分布式环境下就不适用了。一般情况下是通过在数据库端做文章，比如通过唯一性索引或者悲观锁来保障其数据一致性。当然任何方案都是有代价的，这就需要具体情况下来权衡。

另外，java1.5以后提供了一套提供原子性操作的类，有兴趣的可以研究一下它是如何在软件层面保证原子性的。

4）锁的合理使用

大家都知道可以用锁来解决并发问题，但在具体使用上还有很多讲究，比如：

• 每个共享的可变变量都需要由一个个确定的锁保护。
• 一旦使用了锁，就意味着这段代码的执行就丧失了操作系统多道程序的特性，会在一定程度上影响性能
• 锁不能解决在分布式环境共享变量的并发问题