并发安全
类的线程安全定义:
如果多线程下使用这个类,不管多线程如何使用和调度这个类,这个类总是表示出正确的行为,这个类就是线程安全的。
类的线程安全表现为:
1,操作的原子性
2,内存的可见性
不做正确的同步,在多个线程之间共享状态的时候,就会出现线程不安全。
怎么才能做到类的线程安全?
1,栈封闭:
所有的变量都是在方法内部声明的,这些变量都处于栈封闭状态,都是线程安全的。
2,无状态:
没有任何成员变量的类,就叫无状态的类。
3,让类不可变:
让状态不可变,两种方式:
1,加final关键字,对于一个类,所有的成员变量应该是私有的,同样的只要有可能,所有的成员变量应该加上final关键字,但是加上final,要注意如果成员变量又是一个对象时,这个对象所对应的类也要是不可变,才能保证整个类是不可变的。
2、根本就不提供任何可供修改成员变量的地方,同时成员变量也不作为方法的返回值。
4,volatile:
保证类的可见性,最适合一个线程写,多个线程读的情景。
5,加锁和CAS。
6,安全的发布:
类中持有的成员变量,特别是对象的引用,如果这个成员对象不是线程安全的,通过get等方法发布出去,会造成这个成员对象本身持有的数据在多线程下不正确的修改,从而造成整个类线程不安全的问题。
Servlet:
不是线程安全的类,为什么我们平时没感觉到:
1、在需求上,很少有共享的需求。
2,接收到了请求,返回应答的时候,都是由一个线程来负责的。
线程安全问题
死锁
资源一定是多于1个,同时小于等于竞争的线程数,资源只有一个,只会产生激烈的竞争。
死锁的根本成因:获取锁的顺序不一致导致。
有n个进程,共享的同类资源数为m,则避免死锁的最少资源数是n(m-1)+1。
产生死锁的原因:
1,因为系统资源不足
2,进程运行推进的顺序不合适
3,资源分配不当等
产生死锁的四个必要条件:
1,互斥条件:一个资源每次只能被一个进程使用
2,请求与保持条件:一个进程因请求字眼而阻塞时,对已获得的资源保持不放
3,不可剥夺条件:进程已获得的资源,在未使用完之前,不能强行剥夺
4,循环等待条件:若干进程之间形成一种头尾相接的循环等到资源关系
怀疑发送死锁:
简单的死锁:
1,通过jps 查询应用的 id,
2,再通过jstack id 查看应用的锁的持有情况
解决办法:保证加锁的顺序性
动态的死锁:
动态顺序死锁,在实现时按照某种顺序加锁了,但是因为外部调用的问题,导致无法保证加锁顺序而产生的。
例如:
void test(Account fromAccount,Account toAccount){
synchronized (fromAccount) {
synchronized (toAccount) {
}
}
}
虽然内部固定了加锁的顺序,但是外部传入的锁的顺序不一样,所以可能造成死锁。
解决:
1、 通过内在排序,保证加锁的顺序性(调用System.identityHashCode(obj)获取原始的hashcode值,再排序确定顺序,如果hash值一样了,就在外部再定义一个锁,让这两个线程去竞争一次这个锁,谁拿到锁再进入依次获取之前两个锁)
2、 通过尝试拿锁,也可以,在传入的对象内部定义显示锁,然后自旋,依次调用tryAcquired,尝试拿锁,拿不到就自旋再获取:
while(true) {
if(from.getLock().tryLock()) {
try {
if(to.getLock().tryLock()) {
try {
}finally {
to.getLock().unlock();
}
}
}finally {
from.getLock().unlock();
}
}
SleepTools.ms(r.nextInt(10));//休眠一个随机数,否则会发生活锁。
}
}
3、 银行家算法是一种最有代表性的避免死锁的算法。又被称为“资源分配拒绝”法。在避免死锁方法中允许进程动态地申请资源,但系统在进行资源分配之前,应先计算此次分配资源的安全性,若分配不会导致系统进入不安全状态,则分配,否则等待。为实现银行家算法,系统必须设置若干数据结构。
活锁
尝试拿锁的机制中,发生多个线程之间互相谦让,不断发生拿锁,释放锁的过程,比如线程1尝试拿到A锁,尝试拿B锁失败,线程2尝试拿到B锁,尝试拿A锁失败,这样线程1和线程2都循环再次尝试获取两个锁,这时候又是之前的情况。
解决办法:每个线程休眠随机数,错开拿锁的时间。
线程饥饿
低优先级的线程,总是拿不到执行时间。
性能和思考
使用并发的目标是为了提高性能,引入多线程后,其实会引入额外的开销,如线程之间的协调、增加的上下文切换,线程的创建和销毁,线程的调度等等。过度的使用和不恰当的使用,会导致多线程程序甚至比单线程还要低。
衡量应用的程序的性能:服务时间,延迟时间,吞吐量,可伸缩性等等,其中服务时间,延迟时间(多快),吞吐量(处理能力的指标,完成工作的多少)。多快和多少,完全独立,甚至是相互矛盾的。
对服务器应用来说:多少(可伸缩性,吞吐量)这个方面比多快更受重视。
我们做应用的时候:
1、 先保证程序正确,确实达不到要求的时候,再提高速度。(黄金原则)
2、 一定要以测试为基准。
一个应用程序里,串行的部分是永远都有的。
Amdahl定律 : 1/(F+(1-N)/N) F:必须被串行部分,程序最好的结果, 1/F。
影响性能的因素
1,上下文切换:
是指CPU 从一个进程或线程切换到另一个进程或线程。一次上下文切换花费5000~10000个时钟周期,几微秒。在上下文切换过程中,CPU会停止处理当前运行的程序,并保存当前程序运行的具体位置以便之后继续运行。从这个角度来看,上下文切换有点像我们同时阅读几本书,在来回切换书本的同时我们需要记住每本书当前读到的页码。
上下文切换通常是计算密集型的。也就是说,它需要相当可观的处理器时间。所以,上下文切换对系统来说意味着消耗大量的 CPU 时间,事实上,可能是操作系统中时间消耗最大的操作。
2,内存同步:
一般指加锁,对加锁来说,需要增加额外的指令,这些指令都需要刷新缓存等等操作。
3,阻塞:
会导致线程挂起【挂起:挂起进程在操作系统中可以定义为暂时被淘汰出内存的进程,机器的资源是有限的,在资源不足的情况下,操作系统对在内存中的程序进行合理的安排,其中有的进程被暂时调离出内存,当条件允许的时候,会被操作系统再次调回内存,重新进入等待被执行的状态即就绪态,系统在超过一定的时间没有任何动作】。很明显这个操作包括两次额外的上下文切换。
优化性能
1,减少锁的竞争
2,减少锁的粒度:
使用锁的时候,锁所保护的对象是多个,当这些多个对象其实是独立变化的时候,不如用多个锁来一一保护这些对象。但是如果有同时要持有多个锁的业务方法,要注意避免发生死锁
缩小锁的范围
对锁的持有实现快进快出,尽量缩短持由锁的的时间。将一些与锁无关的代码移出锁的范围,特别是一些耗时,可能阻塞的操作
3,避免多余的缩减锁的范围:
两次加锁之间的语句非常简单,导致加锁的时间比执行这些语句还长,这个时候应该进行锁粗化—扩大锁的范围。
4,锁分段:
ConcurrrentHashMap就是典型的锁分段。
5,替换独占锁:
在业务允许的情况下:
1、 使用读写锁,
2、 用自旋CAS
3、 使用系统的并发容器