企业解决方案怎么写,湖南广告优化,wordpress 灯鹭,网站seo诊断优化分析该怎么做复习上节内容#xff08;部分-掌握程度不够的#xff09;
加锁#xff0c;解决线程安全问题。 synchronized关键字#xff0c;对锁对象进行加锁。 锁对象#xff0c;可以是随便一个Object对象#xff08;或者其子类的对象#xff09;#xff0c;需要关注的是#xff…复习上节内容部分-掌握程度不够的
加锁解决线程安全问题。 synchronized关键字对锁对象进行加锁。 锁对象可以是随便一个Object对象或者其子类的对象需要关注的是是否是对同一个锁对象进行加锁锁竞争
进入代码块加锁 离开代码块解锁。
synchronized修饰普通方法相当于给this加锁锁对象this synchronized修饰静态方法相当于给类对象加锁 从导致线程安全问题的原因进行解决。
synchronized续 上一篇
synchronized特性。
synchronized加锁效果具有互斥性。可重入 拿到锁的线程再次对该锁对象进行加锁不会阻塞 [ 代码示例 ]
Thread t new Thread(()-{synchronized(locker){synchronized(locker){System.out.println(hello);}}
});解释 1上述代码可以正常打印hello。 2原因 这两次加锁是在同一个线程进行的。 当前由于是同一个线程此时锁对象就知道了第二次加锁的线程就是持有锁的线程。第二次操作就可以直接放行通过不会出现阻塞。 ——可重入所以这个代码并不会出现锁冲突 3好处 a.可以避免上述代码出现死锁的情况。Java中的锁都是可重入锁。 如果没有这个特性——比如C,用的std::mutex锁就是不可重入的一旦以上代码出现阻塞无法自动恢复所以这个线程就卡死了 ~ ~这里出现的卡死就称为“死锁” b.其他容易出现这种死锁的情况 方法/函数的调用关系复杂加锁的代码比较隐蔽。如下例
void func1(){加锁func2();解锁
}void func2(){func3();
}void func3(){func4();
}void func4(){加锁……解锁
}以上示例的代码直观上看每个地方都是只加了一次锁。 但是由于复杂的调用关系就可能导致加锁重复了。
4注意双重加锁本身就是代码写的有问题是有问题的代码逻辑本来就不应该这样写所以也没有应用场景 ~ ~ 可重入这个特性就是为了防止咱们在“不小心”中引入问题就算你不小心了也没事即写错了也能正常运行
5原理如何能实现可重入性
可重入锁
内部持有两个信息 a.当前这个锁是被哪个线程持有的 b.加锁次数计数器 初始值为0加锁一次1一次第一次加锁——也就是为0的时候加锁会同时记录线程是谁 判定当前加锁线程是否上持有锁的线程如果不是同一个线程阻塞如果是同一个线程就只是让计数器即可 ~ 没有别的操作了 ~ ~
注意 a.synchronized嵌套多层也可以保证在正确的时机解锁 b.计数器是真正用来识别解锁时机的关键要点 ~ ~ 这个源码在JVM中C代码实现出来的在idea中是看不到的 【源码】 Java标准库的源码这个是通过Java代码写的idea中都能看到虽然是.class的但是idea上你看到的是idea自动帮你反编译的 JVM里的源码C写的在Java层看不到需要额外下载jvm的源码来看 ~ ~ c.最外层的{进行加锁最外层的}进行解锁 一共只有一把锁一个锁对象只有一把锁 d.锁的加锁次数和线程不能通过函数进行获取由JVM封装好了我们知道就行不必去干预 e.接d.jconsole可以查看到的是线程的状态能一定程度上反应出锁的状态但是并不能获取锁的这两个信息属性
PS【计数器】这种处理方式很多地方都会使用到可以理解为一种处理技巧。 死锁
——多线程代码中的一类经典问题 ~ ~ 也是经典面试题 加锁是可以解决线程安全问题但是如果加锁方式不当就可能产生死锁。
死锁属于程序中最严重的一类bug。一旦出现死锁线程就“卡住了”无法继续工作。所以要想办法避免 ~ ~
【死锁的三种典型场景】 一个线程一把锁 刚才的代码中如果是不可重入锁并且只有一个线程对这把锁加锁两次就会出现死锁。 两个线程两把锁 线程1 获取到 锁A 线程2 获取到 锁B 接下来1尝试获取B2尝试获取A。 就同样出现死锁了 举例 “互不相让不懂合作僵持不前”执行完run线程才是结束这里是僵持住们无法结束了 运行这个代码打开jconsole进行查看 上边这个例子中如果约定加锁顺序先对A加锁后对B加锁 ~ ~此时死锁仍然可以解决 ~ ~ N个线程M把锁 哲学家就餐问题 注意上图中每个滑稽都只能拿挨着他的两只筷子 以上描述完“哲学家就餐问题”吃面条——去CPU上运行思考人生——放下CPU被调度走拿筷子——加锁
要想解决死锁问题就要能够了解原因 ↓↓↓ 【产生死锁的四个必要条件 ~ ~】 互斥使用。最基本的特性不太好破坏 获取锁的过程是互斥的。一个线程拿到了这把锁另一个线程也想获取就需要阻塞等待。 不可抢占。锁最基本的特性不太好破坏 一个线程拿到了锁之后只能主动解锁不能让别的线程强行把锁抢走 ~ ~ 请求保持。代码结构不一定能破坏要看实际需求 ~有时候代码就是需要两个锁都拿到 一个线程拿到了锁A之后在一直持有A没有释放的前提下总是尝试获取B。 循环等待/环路等待代码结构相关最容易破坏 ~ ~只需要制定一定的规则就可以有效的避免循环等待比如指定加锁顺序 ~ ~
解决死锁问题核心思路破坏上述的必要条件之一就搞定
【解决死锁】从原因入手第四条最容易突破有很多种方案 ~ ~ 1引入额外的筷子 2去掉一个线程 3引入计数器限制最多同时多少个人同时吃面 》123这三个方案虽然不复杂但是普适性不高有的时候用不了 ~ ~
4引入加锁顺序的规则普适性高方案容易落地 5“银行家算法” 能解决死锁问题但是这个方案太复杂了理论可行实践中并不推荐。实际开发中千万不要这么做。先不谈解决死锁问题很可能你写的银行家算法本身就存在bug。
【问题】“可不可以给‘哲学家’编号反正每次只能有一位哲学家吃让他们按编号用餐” 答不行。 线程调度的大前提是“随机调度”。 想办法让某个线程 先加锁违背了“随机调度”根本原则。可行性是不高的。 而约定加锁顺序在写代码的层面上是非常容易做到的 ~ ~ Java标准库中的线程安全类
标准库有很多 集合类
——这些类都线程不安全。 多个线程尝试修改同一个上述的对象就很容易出现问题 注意这里“很容易出现问题”而不是100%也可能这个代码写出来后是没有问题的具体代码具体分析。多线程的代码稍微变化一点就可能有不一样的结果 这几个类自带锁了 ~ ~ 在多线程环境下的时候能好点儿 ~ ~ 但是也不是100%不出问题只是概率比上面小很多。具体代码具体分析 多线程的代码稍微变化一点就可能有不一样的结果 注意这几个类都是标准库即将弃用的 ~ ~现在暂时还保留着未来某一天新版本的jdk可能就把这些内容删了 ~ ~所以在写新的代码的时候就尽量别用了不推荐 ~ ~
拓展【jdk版本升级】
之前用的一直是jdk8这个经典版本2014年发行。之后要学到SpringSpring升级到3之后不支持jdk8了最低也需要jdk17.
另外Spring升级了旧版本的Spring虽然仍然能使用但是修改起来非常麻烦所以还是建议采用用jdk17这种方案。
jdk的版本升级虽然快但是新版本的新东西不算多 ~ ~
【更改方法】
下载安装jdk17然后把idea设置一下使用jdk17即可 ~ ~并不费事不要退缩继续讲解引起线程安全问题的原因
内存可见性
如果一个线程写一个线程读也是可能有线程安全问题的。
代码示例
//这个代码中预期通过t2线程输入的整数只要输入的不为0就可以使t1线程结束。public static int flag 0;//public 类中的成员变量
public static void main(){Thread t1 new Thread(()-{while(flag 0){//循环体里啥都不写}System.out.println(t1 线程结束);});Thread t2 new Thread(()-{System.out.println(请输入 flag 的值);Scanner sc new Scanner(System.in);flag sc.nestInt();});t1.start();t2.start();
}【预期】通过t2线程输入的整数只要输入的不为0就可以使t1线程结束。
【问题】实际输入非0的时候发现t1并没有真的结束
以上代码出现问题的原因 1JVM对代码做出了优化。 t1的循环体内什么都没有写核心指令就只有两条a.load读取内存中flag的值到CPU寄存器里。b.拿着寄存器的值和0进行比较条件跳转指令 ~ ~ 所以上述循环执行速度就会非常快a、b两条指令快速、反复的执行这样在这个执行过程中有两个关键要点①load操作执行的结果每次都是一样的想要输入也是过几秒才能输入人并没有那么快。在这几秒之内已经执行了不知道多少次循环上百亿次 ~ ~②load操作它的开销远远超过条件跳转访问寄存器的速度远远超过访问内存频繁执行load和条件跳转load的开销大并且load的结果又没有变化真正出现变是好几秒之后的事用户输入。此时JVM就产生怀疑这里的load操作是否真的有存在的必要——JVM就可能做出代码优化 ~ ~JVM把上述load操作给优化掉只有前几次执行load后续发现load反正都一样静态分析代码也没看到哪里改了flag因此就直接激进的把load操作给干掉了load操作被干掉之后就相当于不再重复读内存,而直接使用寄存器中之前“缓存”的值 ~ ~大幅地提高了循环的执行速度不过也因此导致t2修改了flag的内容但是t1没有看到这个内存的变化**》内存可见性问题**2t2修改了内存但是t1没有看到这个内存的变化所谓内存可见性
以上两条原因1导致了2进而导致程序出现了问题。
【拓展JVM代码优化功能】 其他编译器/JVM都非常厉害。
很多地方都会涉及到代码优化。 确实存在有些程序猿代码写的不太行。因此设计JVM和编译器的大佬就引入这样的优化能力在优化的加持下就能让你即使写不出太高效的代码最终的执行效率也不会太差 ~ ~ ~
有没有优化差别非常大。比如有服务器开启优化10分钟完成启动关闭优化30min
虽然我们写的只是一份代码但是编译器和JVM就能只能分析出当前这份代码哪里不太合理然后对代码进行调整 ~ ~保证了在原有逻辑不变的前提下提高程序效率 ~ ~ 很多主流语言的编译器都有这样的能力对代码进行不合理分析调整逻辑不变效率提升 但是原有逻辑不变这点编译器是没有那么容易正确保持的。单线程下还好多线程下很容易出现误判——这个可以视作bug
【对“多线程代码稍微变化一点就可能有不一样的结果”的一点例子帮助理解】
//其实就是对刚才的代码略加改动在循环体中加入sleep语句
Thread t1 new Thread(()-{while(flag0){try{Thread.sleep(10);//不加sleep一秒钟循环上百亿次//load操作的开销非常大所以优化的迫切程度就更高//加了sleep一秒钟循环1000次//load整体开销就没那么大了优化的迫切程度就降低了。//所以可知编译器什么时候触发优化不一定。进而什么时候出现“内存可见性问题”也就不一定了。代码稍微改动一点结果就截然不同。}catch(InterruptedException e){e.printStackTrace();}}System.out.println(t1线程结束);
}); 解决内存可见性问题【volatile关键字】
——由上述文字可知需要解决“是否选择启用优化”。
【volatile】强制关闭优化/或称强制读取内存。 可以确保示例代码中每次循环都会重新从内存中读取数据
这样做开销是大了效率是低了但是数据的准确性、逻辑的正确性都提高了。 更多时候快没有准重要就加volatile确实有时候需要快而不要求准就不加volatile。根据场景需求作取舍
这样volatile关键字就把是否启用优化 的 选择权 交给了程序猿自己。
【volatile功能】 保证内存可见性核心功能之一 /关于 内存可见性有两种表述/ /1前边说过的 上述代码编译器发现每次循环都要读取内存开销太大。于是就把读取内存操作优化成读取寄存器操作提高效率。/ /2JMMJava Memory Model模型一个抽象的 概念 上述代码编译器发现每次循环都要读取“主内存”就会把数据从“主内存”中复制到“工作内存”中后续每次都是读取“工作内存”/ 工作内存——不是真正的内存而是CPU寄存器 或者 CPU的缓存L1,L2,L3,三级缓存称为“工作存储区”。 主内存——也就是内存。 、、 引入“工作内存”这个概念而不直接说“CPU寄存器”主要是为了“跨平台”。并且不用像说“CPU寄存器或缓存中”这样拗口。 禁止指令重排序 注意
只有锁可以完全解决线程安全问题而 Java 中的锁有两种synchronized 和 Lock。
volatile 可以解决内存可见性问题但不能完全解决线程安全问题。
sleep不能解决线程安全问题。
