Java并发场景及解决方案

工作中，会遇到很多需要控制并发访问的场景，由于大部分项目是分布式的，常用的ReentrantLock、synchronized代码块就会失效。以下案例皆为实战总结

案例一：签到送积分

需求：同一个活动，同一个用户一天仅可参与一次签到

自己踩过的坑：这个需求是毕业之后所做的第一个需求，当时根本没有控制并发的概念，所以结果可想而知。

当时实现思路是：查询数据库该用户在该活动下的上次签到时间，如果今天已经签到，返回已签状态。那么问题来了，如果接口被频繁调用，用户今天未签到，那么多个线程就有可能查出来同一个签到时间，所以很容易就会出现签到重复的情况。

解决方案：应用数据库联合唯一索引，在数据库层面，将用户id、活动id、日期做唯一索引，这样就很容易达到预期需求。

案例二：参与活动抽幸运号，每100个用户为一期

需求：用户参与活动，得到一个幸运号，幸运号为1-100，幸运号的生成按照顺序依次增加，每100个人为一期活动，有一个期号

分析：首先需要保证用户的幸运号在一期中一定是唯一的，不能有重复现象，另外，需要保证必须为100个一期，不能增加至101等。

解决方案：应用数据库的自增主键，这样很容易实现用户幸运号的唯一，那么是有一个问题，幸运号会一直增加，这个其实不用担心，展示给用户的时候取余就可以了。另外，要保证每100个幸运号为一期，并且有相同的期号，可以在参与的时候给一个默认期号，跑一个定时，当参与记录有100个默认期号的时候进行期号更新，更新最大期号。

案例三：优惠券领取

需求：领取优惠券时，优惠券有限制“每天总领取张数”，“用户总共可领取该优惠券的张数”，必须很好的控制这个数量，保证优惠券发放准确。

分析：优惠券领取之前，肯定得判断优惠券是否已达到总领取张数，该用户是否已达到自身最大可领取张数。如用数据库记录的话，查出来数量的时候有可能其他线程已经进行了更新，容易发超。

解决方案：redis的自增incr是原子性操作，增加之后返回自增之后的值，那么可以将优惠券领取作为key，领取张数作为值，同理，将用户领取作为key，领取张数作为值，每次领取之前进行各自的自增操作，然后进行临界值判断，若超出，则提醒用户，并进行自减操作。

另，因为我们公司的优惠券券号是提前生成好的，所以也会以队列的形式存放在redis里。利用lpop等操作保证券码被唯一使用。

以上是自己在工作中使用到的控制并发采用的方法，总结了一下，主要是以下几点：

1.分布式服务，资源数据存放位置唯一，可在该方面寻求解决方法

数据库的唯一索引、强检验、id自增、乐观锁，redis的原子操作等

2.分布式服务，可通过方案设计将并发访问变成串行访问，很好的避免并发