Java解决高并发下商品库存更新

1、问题分析
先来就库存超卖的问题做描述：通常电子商务网站都会遇到如团购、秒杀、特价之类的活动，而这样的活动有一个共同的特色就是访问量激增、上千甚至上万人抢购一个商品。
然而，做为活动商品，库存确定是颇有限的，如何控制库存不让出现超买，以防止形成没必要要的损失是众多电子商务网站程序员头疼的问题，这同时也是最基本的问题。
从技术方面剖析，不少人确定会想到事务，可是事务是控制库存超卖的必要条件，但不是充分必要条件。

正常状况下咱们会这样写：
//得到商品库存
select counts from goods where id=?
//对比库存和下单时购买商品数量
if(counts<buyAmount){
    //库存不足...
}else{
    //业务代码...更新库存..
}
大多数人都会这么写，看似问题不大，其实隐藏着巨大的漏洞：
数据库的访问其实就是对磁盘文件的访问，数据库中的表其实就是保存在磁盘上的一个个文件，甚至一个文件包含了多张表。例如因为高并发，当前有多个用户进入到了这个事务中，
这个时候会产生一个共享锁，因此在select的时候，这多个用户查到的库存数量都是N个，同时还要注意，mysql innodb查到的结果是有版本控制的，
再其余用户更新没有commit以前(也就是没有产生新版本以前)，当前用户查到的结果依然是N；
而后是update，假如这多个用户同时到达update这里，这个时候update更新语句会把并发串行化，也就是给同时到达这里的多个用户排个序，一个一个执行，并生成排他锁，
在当前这个update语句commit以前，其余用户等待执行，commit后，生成新的版本；这样执行完后，库存或许为负数了。

改进版：
把上面的代码稍微改动一下，能够避免这样状况发生
//更新库存
update goods set counts=counts-buyAmount where  id=?
//获取当前商品库存
select counts from goods where id=?
//判断库存是否为负数
if(counts<0){
    //回滚事务
}else{
    //业务代码...更新库存..
}

可是==========================
在高并发的状况下，确定不能如此高频率的去读写数据库，会严重形成性能问题的
必须使用缓存，将商品放入缓存中，并使用锁来处理其并发状况。当接到用户提交订单的状况下，先将商品数量递减（加锁/解锁）后再进行其余方面的处理，处理失败在将数据递增1（加锁/解锁），
不然表示交易成功。当商品数量递减到0时，表示商品秒杀完毕，拒绝其余用户的请求。