多线程并发竞争共享资源时的技术解决方案

最近开始接口商品下单支付，水电煤缴费等可能存多线程竞争统一资源导致数据溢出的问题，如商品库存剩余为100，同时由100个线程在竞争这个资源，那么如何保证只有第一个线程抢到资源，而其他的线程无法购买。以往的管理系统方面有碰到这块但一般由于不涉及支付等金额购买的情况，同时也没有这么高并发，所以没有在意。但现在移动互联网 特别是这种商品购买，订单支付等必须要保证多线程下共享资源如库存，客户余额修改不会出现问题.所以特意今天看了下 SSM+redis是如何解决这种高并发问题，例子是一个3W人抢2W个红包的例子，当然以前也有像抢火车票等高并发业务场景，但那时候仅仅只是用了个synchronzied排他悲观锁的方式去控制，以降低系统吞吐作为代价.如果作为demo例子还阔以，但是实际用户环境会导致 体验差,还容易出现问题。

关于多线程并发的几种解决方案

1. 悲观锁:在涉及共享资源修改的时候，锁定数据库中的该条记录通过for update的方式控制某一时刻 修改数据的线程数量.
2. 乐观锁+可重入机制：乐观锁存在ABA等问题，故需要对共享资源表添加version版本号，每次修改version版本号+1的方式，在查询与修改之间数据version版本未发生变化则可以修改，发生变化启用重试while+continue重试机制（重试3次）保证数据不会出现问题,修改失败 手动事物回滚.
3. redis控制：redis缓存共享数据，每次修改redis中的数据，最后如果库存为0,修改一次数据库数据.