Java EE——线程安全集合类和死锁

线程安全集合类

之前讲过，像Vector，Stack，HashTable等都是线程安全的，但是并不建议使用，因为加的锁过于沉重，降低了效率
因此我们在使用这些集合的时候为了保证线程安全，最好自己加锁

多线程使用ArratList

自己加锁

使用synchronized或者ReentrantLock

使用标准库方法

Collections.synchronizedList(new ArrayList);

这是标准库提供的，相当于给我们的ArrayList套了一个壳，让其在关键操作上都带有synchronized

使用CopyOnWriteArrayList

使用不加锁的方法保证线程安全，这个方法也叫写时拷贝

当若干个线程在读顺序表中的数据时，我们让他们并不直接读取顺序表，而是通过中间的一个引用间接访问顺序表。而当另一个线程修改顺序表时，就先拷贝一份顺序表，在改好所有的数据，最后把之前的那个引用变成这个新的顺序表
这样的话，我们的读顺序表的线程读到的数据就要么都是旧数据，要么都是新数据了，不会出现修改了一半的情况

类似的，显卡渲染画面也是类似的原理，当显卡渲染画面时，先渲染一帧，显示到显示器上，同时再渲染下一帧，渲染好了就覆盖给上一帧

优点

没有锁，提高了效率和性能

缺点

占用的资源较多
新数据要隔一段时间才能获取到

多线程使用队列

可以参考之前讲的阻塞队列

1. ArrayBlockingQueue
2. LinkedBlockingQueue
3. PriorityBlockingQueue
4. TransferQueue 最多只包含一个元素

多线程使用哈希表

HashTable

只在关键的方法上加了synchronized，因此相当于直接对HashTable对象进行加锁，如果多个线程访问一个对象，那么就会直接造成冲突

ConcurrentHashMap

只给写操作加锁，读操作没有锁
这相当于只有两个线程同时修改数据才会发生锁冲突，一个线程修改一个线程读就不会发生锁冲突

并且ConcurrentHashMap中用到volatile来保证读到最新的数据

ConcurrentHashMap是多把锁，每个哈希桶都有一把锁，这样的话只有两个线程访问同一个哈希桶才会发生冲突

并且，ConcurrentHashMap还使用了CAS，保证了效率

对于扩容操作，使用了化整为零的操作
如果数据量很多，那么在扩容时拷贝就需要耗费大量时间，这个时候可能就让服务器的请求超时
而ConcurrentHashMap会先开辟好一份新的内存，每次put操作时，都会将一小部分的旧地址的数据拷贝到新地址上，新的和旧的会同时存在一段时间，直到所有的数据都搬运完成，再销毁旧的数据，保证我们访问的连续性

HashMap的key允许为空，而HashTable和ConcurrentHashMap不可以

死锁

原因

1

一个线程同时加锁两次，并且锁是不可重入锁

2

有A线程和B线程，有X锁和Y锁，A线程获取到了X锁，B线程获取到了Y锁，在代码中，A线程想要Y锁，而B线程想要X锁

3

多个线程多个锁——哲学家就餐问题
5个哲学家围一个圆桌吃饭，每个人左右都是一根筷子，如果五个哲学家同时拿起左手的筷子，并且不撒开，那么就会死锁

死锁的条件

1. 互斥使用 线程a使用锁时，线程b不能用
2. 不可抢占 线程a使用时，线程b不能把锁抢走
3. 请求和保持 线程a拿到X锁后，不释放这个锁，并且还要拿到Y锁
4. 循环等待 线程A和B都拿着对方想要的锁，并且都等着对方释放锁

死锁的解决

通过研究这些死锁的条件，我们可以给出解决方法
由于条件1和2都是锁自身的特性，因此无法打破，否则就不存在锁的概念了

而条件3可以打破，我们可以让代码不这么写——一个线程加锁一个代码后必须释放了才能拿到另一个锁，但是并不是所有代码都可以这么改

而条件四也可以打破，我们可以调整线程的加锁顺序，让线程A和B都先加锁X锁，后加锁Y锁

对于多个锁，我们可以约定先加锁编号小的，这样的话哲学家问题就有一个人无法拿到两个筷子，就会有人先吃完饭，放下筷子，再给别人使用了