情景假设：卖主A现在只剩下一件热门商品，同时有N[N>1000]个买主都看中了这件商品。
个人解决办法：
在事务环境中使用锁机制。
sql描述：select count(*) from bid where bid.item_id=1 for update;
然后根据数量决定是否要插入数据。
疑问：这样的设计在高并发环境下性能如何？或者这样的做法合理吗？或者有没有更好的解决办法呢？
期待....
many thanks！
我这样理解你的话不知道对不？
把item的数量加载到内存中去。使用concurrent包中提供的atom类
当其买主如果要执行购买操作之前，必须获得item的数量上的锁
并发同步情况下使用线程锁，就没有严格的先来后到，当然也要考虑公平锁和非公平锁的问题，尽量让先发出请求的线程锁住资源，但最终是由CPU来控制的，或者使用Future.get和Callable这样新的并发API来解决。
针对于商品与买家的关系可以有以下的一些方法实现：
1.对可用资源建立一个队列将所有的申购排队，按照先后顺序逐一提交，只有当前一个人申购失败之后才允许下一个申购。在你的业务过程中这个排队也许是长期的，就像论坛里买东西的申购排队一样（常见“排队”等的回帖），第二个人的申购请求可能是在好多天之后才开始进入处理过程的，而他之后还有好几个人在等待呢。这里涉及到了持久化消费者session的过程，实现难度可能会比较大。
2.对可用资源建立一个队列将所有的申购排队，第一个入队的可以提交申请，当队列发现剩余资源不足的时候剩下的所有请求都会被拒绝掉，被拒绝的人可以再次提出申购请求，同时对于该资源不再保留消费者队列。直到检查发现资源再次可用的时候，才开启此资源的申购队列。相比较与上一种方案此时不需要考虑申购者的session维护，实现难度下降很多了。
前2中方案实际上是在控制申购者的操作能否发生。
3.消费者乱序竞争先到者将资源锁定，完成消费过程后解锁此后开始下一轮的竞争。此时同样需要考虑等待被锁定资源的申购者session是否需要持久化。
此种方案实际上是在控制资源，使它保持独占使用。
无论是哪一种方式都已经不是在考虑“数据”，无论资源还是消费者都是脱离数据的对象。对于“2”这个数字的锁定是没有意义的，对于“xx显示器”这个资源的锁定是可以被理解的，对于消费者也是同理。