并发编程理论基础——安全性、活跃性以及性能问题【并发编程宏观角度来看会出现的问题】（六）

发编程当中需要注意的问题（解决手段包括不限于并发工具类和合理科学的设计模式）

1. 安全性问题：可见性，同步机制
2. 活跃性问题：死锁，活锁，饥饿
3. 性能问题：线程的上下文切换

安全性问题（不局限于Java提供的锁，也可以是别的工具提供）

1. 需要分析是否存在原子性、可见性、有序性问题的是有多个线程会同时读写同一数据的情况。
2. 数据竞争：多个线程会同时访问同一数据，并且至少有一个线程会写数据时
3. 竞态条件：指的是程序的执行结果依赖线程执行的顺序
   • 比如在并发场景中，程序的执行依赖于某个状态变量，当某个线程发现状态变量满足执行条件后，开始执行操作；可是就在这个线程执行操作的时候，其他线程同时修改了状态变量，导致状态变量不满足执行条件了。
4. 解决方案：关于数据竞争和竞态条件问题：互斥来解决，统一归为：锁（同一时刻只有一个线程执行）

活跃性问题（观看Thread可以考虑了解JVM的工具命令行）

1. 指的是某个操作无法执行下去
2. 包含死锁、活锁、饥饿
3. 死锁：一组互相竞争资源的线程因互相等待，导致永久阻塞的现象
4. 活锁：有时线程虽然没有发生阻塞，但仍然会存在执行不下去的情况
   • 比如线程A和线程B执行到同一个资源，两个线程都互相谦让希望对方先执行，
   • 如果一直没完没了地“谦让”下去，就会成为没有发生阻塞但依然执行不下去的“活锁”。
   • 解决方案：谦让时，尝试等待一个随机的时间就可以了，这样同时相撞后再次相撞的概率就低了
5. 饥饿：指的是线程因为无法访问所需资源而无法执行下去的情况
   • 线程优先级不均，在CPU繁忙时，优先级较低的线程可能就没有机会执行；
   • 持有锁的线程，如果执行的时间过长，也可能导致饥饿
   • 解决方案：
     1. 保证资源充足
     2. 公平分配资源
     3. 避免持有锁的线程长时间执行
   • 1和3适用场景有限，主要还是2，公平分配资源会考虑用到公平锁，一种先来后到的方案，线程的等待是有顺序的，排在等待队列前面的线程优先获取资源（基本上没有必要，不要使用公平锁）

性能问题（度量指标应该有一套完整的标准体系，过于空泛得不出好的性能方案，有些技术是好技术，但可能并不适用所有场景）

1. 过度使用锁可能导致串行化的范围过大，这样就不能够发挥多线程的优势了，而我们之所以使用多线程搞并发程序，为的就是提升性能。
2. 解决方案：
   • 第一，使用无锁的算法和数据结构，比如线程本地存储（TLS）、写入时复制（Copy-on-write）、乐观锁等；Java 并发包里面的原子类也是一种无锁的数据结构；Disruptor 则是一个无锁的内存队列，性能都非常好
   • 第二，减少锁持有的时间。互斥锁本质上是将并行的程序串行化，所以要增加并行度，一定要减少持有锁的时间。这个方案具体的实现技术也有很多，例如使用细粒度的锁，一个典型的例子就是 Java 并发包里的 ConcurrentHashMap，它使用了所谓分段锁的技术；还可以使用读写锁，也就是读是无锁的，只有写的时候才会互斥。
3. 性能方面的度量指标
   • 吞吐量：指的是单位时间内能处理的请求数量。吞吐量越高，说明性能越好。
   • 延迟：指的是从发出请求到收到响应的时间。延迟越小，说明性能越好。
   • 并发量：指的是能同时处理的请求数量，一般来说随着并发量的增加、延迟也会增加。所以延迟这个指标，一般都会是基于并发量来说的。例如并发量是 1000 的时候，延迟是 50 毫秒。