java如何效率的解决这个抢房间座位问题

Question

java.util.concurrent.ExecutorService
java.util.concurrent.Executors
java.util.concurrent.Semaphore
能搞定不？

Answer 1

你实测过加锁带来的性能开销么？别老妄想一些“多快好省”的方法可以解决问题，在你的业务场景里，如果要多线程的“抢座”，就必须要上锁，同步抢座，离开（insert、remove）的操作，这是没有办法绕过的步骤，所以不管加锁开销多大，要么你就接受这个开销，要么就接受数据安全问题这个加锁的过程你想复杂了，可以用concurrenthashmap来做

Answer 2

100个1000个元素加锁控制其实是小意思，你要自己实现的话，可以学习concurrenthashmap里的方法，“分段加锁”，把1000个对象分成10个锁来管理。其实这么少的元素对性能没有什么太大的影响当你的加锁单元多到10w个100w个的时候，可以做一些逻辑上的控制，比如给排队的人编个号标个区，上半区的人只能去前面的房间，即使后面的房间有位置也不许他们坐，这样就把问题简化成为少量加锁单元的场景

Answer 3

我是考虑过用concurrenthashmap来做这个东西，但是仍然存在一个问题，concurrenthashmap只是保证自身操作的那些方法是线程安全的，但是在实际使用时，我首先必须检查concurrenthashmap的一个key（座位）上是不是空的，然后再往里面放人，这是两步操作，于是我必须在concurrenthashmap外面再加一次锁，在完成后解除锁。锁上加锁是不是很囧

Answer 4

我是考虑过用concurrenthashmap来做这个东西，但是仍然存在一个问题，concurrenthashmap只是保证自身操作的那些方法是线程安全的，但是在实际使用时，我首先必须检查concurrenthashmap的一个key（座位）上是不是空的，然后再往里面放人，这是两步操作，于是我必须在concurrenthashmap外面再加一次锁，在完成后解除锁。锁上加锁是不是很囧锁上加锁没什么好囧的，如果要保证安全，你就要设计合理的数据结构，如果你设计出来的结构必须要加锁，那是跑不掉的。不过这个场景如要我来设计，我不会用hashmap这样的数据结构，会转用其他的思路来解决问题

Answer 5

请教如何实现这个通知模型？用什么方式
你可以参考一下observer的模式，java已经提供了代码实现。

Answer 6

请教你的思路谢谢做一个阻塞队列维护一个唯一的token队列就好了，每个token对应一个座位，这样你的场景就简化成为简单的 生产者-消费者 场景了