Java持续实践

delete from form where id not in (select min(id) from form group by parent_id, tenant_id);

面试被问到这个问题, 但其实之前的文章有写.https://blog.csdn.net/qq_33229669/article/details/108306727线程执行yield方法后, 依然还是runnable即使刚刚放弃了执行的权利, 也可能下一次就被调度回来了.yield和sleep的区别: 是否随时可能再次被调度. sleep期间, 它是已经被阻塞了, 不会把它再调度起来. 但是yield是暂时把调度权让给其他线程, 下次也可能会被调度到.再次复习一下线程的状态图:...

文章目录关于死锁的面试问题关于死锁的面试问题写一个必然死锁的例子，生产中什么场景下会发生死锁？可以参考如下的文章, 必然死锁的例子.https://javaweixin6.blog.csdn.net/article/details/108460550什么场景容易发生死锁：最明显的就是一个方法中获取多个锁，或者在一个方法中获得了锁, 此时再去调用其他的方法, 其他的方法又获得锁了, 这样也可能造成死锁.实际业务中, 库存的增减, 金钱的转移是有可能会发生死锁的.发生死锁必须满足哪些条件？htt

文章目录线程活跃性问题之--饥饿线程活跃性问题之–饥饿当线程需要某些资源(通常是CPU资源) , 但却始终获得不到.造成饥饿的情况:线程的优先级设置得过低有某个线程持有锁, 同时又无限循环而不释放锁某程序始终占用某文件的写锁对应的解决办法程序中不要设置优先级程序中不要有不释放锁的逻辑错误线程饥饿的影响:造成系统的响应性变差.例如前端浏览器某个线程处理打开图片,播放视频等操作,此时后台线程负责图片,视频的IO操作等,如果后台线程把CPU资源全部占用了, 那么前台线程始终得不

文章目录活性故障活锁 (Livelock)工程中的活锁实例: 消息队列活性故障死锁是最常见的活跃性问题, 除了死锁外, 还有类似的问题导致程序无法顺利的执行, 统称为活跃性问题. 例如 活锁 (Livelock) 饥饿活锁 (Livelock)什么是活锁活锁具有两个特点,第一个是线程没有阻塞, 始终在运行中(所以叫活锁, 线程是活的, 运行中的. )第二个特点: 程序却得不到进展, 因为线程始终重复同样的无效事情.如下图 , 两个绅士弯腰, 如果是死锁, 那么就是两个人始终一动不动, 直

文章目录1. 设置超时时间2. 多使用JUC包提供的并发类,而不是自己设计锁3. 尽量降低锁的使用粒度4. 尽量使用同步方法 而不是同步代码块5. 给线程起有意义的名字6. 避免锁的嵌套7. 分配锁资源之前先看能不能收回来资源8 . 专锁专用1. 设置超时时间使用JUC包中的Lock接口提供的tryLock方法.该方法在获取锁的时候, 可以设置超时时间, 如果超过了这个时间还没拿到这把锁, 那么就可以做其他的事情, 而不是像synchronized如果没有拿到锁会一直等待下去.boolean

文章目录检测与恢复策略死锁的修复策略总结检测与恢复策略检测与恢复策略: 一段时间检测是否有死锁, 如果有剥夺某一个资源 ,打开死锁.死锁的检测算法 :允许发生死锁.每次调用锁的时候 , 都做记录,用图的数据结构来记录.根据有向图的方向, 定期检查 "锁的调用链路"中是否存在环路.一旦发生死锁, 用死锁恢复机制进行恢复.恢复方法1 : 进程终止逐个的终止线程, 直到死锁消除为止.终止的顺序根据优先级终止, 看是前台的交互更加的重要, 还是后台的处理更重要根据已经占用的资源和 还

文章目录哲学家就餐死锁问题四种解决方案服务员检查 (避免策略)改变一个哲学家拿筷子的顺序 (避免策略 代码演示)餐票 (避免策略)领导调节策略 (检测与恢复策略)哲学家就餐死锁问题四种解决方案此文中演示了哲学家就餐问题的死锁代码demo . 下面提供四种解决方案https://javaweixin6.blog.csdn.net/article/details/108541931服务员检查 (避免策略)在哲学家去拿筷子的时候, 由服务员去判断是否会造成五个人都拿着左边筷子的情况, 如果会, 那么服务

文章目录哲学家就餐问题哲学家就餐问题哲学家就餐问题 如下图所示. 哲学家就餐的餐位上, 左手边和右手边分别只有一只筷子.如果要就餐, 就必须拿到左手边和右手边的筷子.流程如下:先拿起左手的筷子再拿起右手的筷子如果筷子被人使用了, 那就等别人用完吃完后, 把筷子放回原位哲学家就餐流程的伪代码如下:就餐问题的死锁风险 :如果某个时刻, 每个哲学家都拿着左手边的筷子, 那么就会永远等待右手边的筷子,...

文章目录死锁的特点与修复策略避免策略代码演示死锁的特点与修复策略死锁的特点:不可提前预料蔓延速度快危害非常大发生死锁后, 要保存案发现场, 可以用java相关的命令, 把整个堆栈信息保存下来, 立刻修复线上服务.利用保存的堆栈信息, 排查死锁, 修改代码. 重新发版.修复死锁的三个策略 :避免策略 : 哲学家就餐的换手方案, 转账换序方案检测与恢复策略: 一段时间检测是否有死锁, 如果有就剥夺某一个资源, 来打开死锁鸵鸟策略: 比喻鸵鸟遇到危险把头埋地上而看不到危险, 逃避心理

文章目录定位死锁--ThreadMXBean定位死锁–ThreadMXBean使用ThreadMXBean 可以检测程序中出现死锁的线程, 获取该线程的相关信息. 做一些对应的操作.相比较于jstack 在命令中查看. 此种写代码的方式, 能够在线程出现死锁的时候, 做一些对应的操作.示例代码如下 :package com.thread.deadlock;import java.lang.management.ManagementFactory;import java.lang.manag

文章目录jstack定位死锁两个线程死锁分析多个线程死锁分析jstack定位死锁死锁发生的时候, 控制台什么也不打印, 无法进行排查. 这个时候就需要借助工具来进行定位死锁了.工具之一就是jdk自带的命令jstack在jdk的bin 目录中,可以看到是有jstack.exe这个应用程序的,配置好了jdk的环境变量后,那么就可以直接用jstack来分析死锁了.两个线程死锁分析首先分析两个线程死锁的情况运行之前的章节中, 两个线程必然发生死锁的代码demopackage com.thread.

文章目录死锁发生的四个必要条件死锁案例解读死锁发生的四个必要条件互斥条件:一个资源同时只能被一个线程所使用.请求与保持条件: 例如请求第二把锁的时候, 保持自身的第一把锁不去释放.不剥夺条件: 进程已获得的资源(例如已经获得的锁),没有外界的力量来去剥夺这把锁.循环等待条件: 两个线程时, 是你等我释放锁, 我等你释放锁. 多个线程时, 是头尾相接的等待.例如下图以上的四个条件,为死锁发生的必要条件, 即必须同时满足这四种情况, 才会发生死锁.死锁案例解读例如此文的例子中.http

文章目录多个人转账发生死锁多个人转账发生死锁人数多的时候, 依然会发生死锁, 遵循墨菲定律.虽然人多的时候发生死锁的几率不高, 但是危害大.此节的代码中, 需要用到上一节的代码, 链接如下.https://javaweixin6.blog.csdn.net/article/details/108475207此节的代码如下 :定义账户的数组, 用于给不同的账户转账.并且给每个账户赋初始值的钱为1000.在TransferThread内部类中继承了Thread类, 重写run方法, 执行NUM

文章目录两个转账的死锁demo两个转账的死锁demo需要两把锁: 转账时, 锁住自己的账户, 同时只能有一个线程去执行转账.获取两把锁成功, 且余额大于0 , 则扣除转出人的钱, 增加收款人的钱. 并且是原子操作.出现死锁的情况: 对方给我转钱 ,我也给对方转钱, 那么双方都持有自己的锁, 并且需要对方的锁, 这就造成了死锁.如下的代码演示了转账死锁的发生.在run方法中, 根据不同线程的flag 执行不同的转账方法,分别给a和b相互的转账.transferMoney方法就是转账的方法.在转

文章目录死锁代码demo死锁代码demo如下的代码为死锁的demo.创建了两个线程, 分别拥有锁o1和o2 ,并且尝试去获取锁o2和o1 ,造成相互等待的阻塞状态.package com.thread.deadlock;/** * 类名称:MustDeadLock * 类描述: 必定发生死锁的情况 * * @author: https://javaweixin6.blog.csdn.net/ * 创建时间:2020/9/8 7:55 * Version 1.0 */publi

文章目录死锁的含义死锁的影响死锁的危害--墨菲定律死锁的含义死锁是一定发生在并发中的.互不相让: 当两个或者更多的线程(或进程)相互持有对方所需要的资源, 又不主动释放锁, 导致所有人都无法继续执行下去, 导致程序陷入无尽的阻塞, 这就是死锁.例如下图,线程A持有锁1 ,想去拿锁2, 线程B持有锁2, 想去拿锁1, 但是此时释放都不释放自己的锁, 那么就会进入无尽的阻塞.锁的特性是只能被一个线程所拥有如果多个线程之间的依赖关系是环形, 存在环路的锁的依赖关系, 那么也可能会发生死锁.如下

文章目录什么是Java内存模型?(重点)volatile和synchronized的异同原子性可见性什么是Java内存模型?(重点)c语言没有内存模型, 在多核情况下表现不一致.有三种概念, JVM内存结构, Java对象模型, Java内存模型.JVM内存结构, Java对象模型可以点击下面的链接查看.JVM内存结构, Java对象模型JMM Java内存模型可以点击下面的链接.JMM Java内存模型重排序 可见性 原子性 是JMM最主要的体现,也是最重要的内容.可以讲讲重排序的例子和

文章目录不同写法对比为什么枚举是最好的单例模式写法使用的注意事项单例模式面试问题不同写法对比饿汉式: 写法简单, 但是没有lazy loading 懒加载懒汉式: 如果写的不好, 会有线程安全问题. 尤其是在判断是否为空的地方静态内部类: 可用 避免了线程安全问题和资源浪费的问题.双重检查模式: 面试使用, 可以体现出很多的JMM知识 . 同时做到了线程安全和懒加载枚举: 最好的写法. 生产中使用.为什么枚举是最好的单例模式写法《Effective Java》 这本书的作者提到, 枚举

文章目录静态内部类(推荐使用)枚举 (推荐实际生产使用)静态内部类(推荐使用)如下为静态内部类的写法:package com.thread.jmm;/** * 类名称:Singleton1 * 类描述: 静态内部类(推荐使用) * * @author: https://javaweixin6.blog.csdn.net/ * 创建时间:2020/9/6 19:26 * Version 1.0 */public class Singleton7 { /** *

文章目录单例模式双重检查的写法双重检查的写法优点与常见问题单例模式双重检查的写法如下为单例模式双重检查的写法, 也是属于懒汉式package com.thread.jmm;/** * 类名称:Singleton1 * 类描述: 双重检查 (推荐面试使用 ) * * @author: https://javaweixin6.blog.csdn.net/ * 创建时间:2020/9/6 19:26 * Version 1.0 */public class Singleton6 {

文章目录单例模式懒汉式的三种写法懒汉式(线程不安全 不可用)懒汉式(线程安全 同步方法 不推荐使用)懒汉式(线程不安全 同步代码块 不可用)单例模式懒汉式的三种写法懒汉式单例模式的概念: 只有需要用到实例的时候才加载, 如果用不到实例, 就不会去加载, 这样就节省了内存空间.懒汉式(线程不安全 不可用)如下的代码是懒汉式(线程不安全)的写法.package com.thread.jmm;import javax.print.attribute.standard.NumberUp;/**

文章目录单例模式的作用单例模式的使用场景饿汉式饿汉式 (静态常量 可用)饿汉式 (静态代码块 可用)单例模式的作用单例模式的好处, 主要有三个:节省内存和计算例如如下的Resource类中, 该类的构造方法的三个属性需要做比较消耗资源的操作, 例如从磁盘数据库中获取一些数据. 因此对于这种类, 最好是只用创建一次就行了, 节省资源和时间.保证结果正确例如当进行多线程统计的时候, 用一个全局的单例计数器去统计, 如果每个线程都用自己的计数器去统计, 那么统计的结果可能就不正确了.方便管

简单的把原子操作组合在一起, 并不能保证整体的操作是原子性的.例如完全同步的HashMap并不完全的安全 . 例如通过Collections工具类创建的同步的HashMapCollections.synchronizedMap(new HashMap<>()) 并不能保证其安全性. 虽然此Map都加了synchronized同步, 但是如果有线程对map中的值取出来, 并且加上某个值, 再put回map中去, 那么此操作就不是原子性的....

关于long和double的原子性在oracle的官方文档中有提到对于double 和long类型, 是存在64位的值的写入的, 可以分为两个32位的操作进行写入的, 那么可能线程读取double和long类型的时候 , 读取其中32位的内容是上一个线程的, 读取下一个32位的内容这个线程 , 可能会造成读取错误. 使用volatile修饰可以保证其原子性.结论 : 在32位的机器上, long和double操作都不是原子的, 但是64位的jvm上是原子的.但是在实际的生产环境中, jvm已经避免

文章目录原子性的介绍Java中的原子操作原子性的介绍原子性是指: 一系列的操作, 要么全部执行成功, 要么全部执行失败, 不会出现执行一半的情况, 这一系列操作是不可分割的.典型的i++操作就不是原子性的. 例如下图中i++是要先读取i, 再加一, 再给赋值回去, 是三步.用synchronized锁把这三个步骤锁起来, 才能实现原子性.Java中的原子操作除了long和double 之外的基本数据类型(int byte boolean short char float)的赋值操作所有

文章目录能保证可见性的措施synchronized作用的升华可见性总结能保证可见性的措施除了volatile 可以让变量保证可见性外.如下这篇文章中,介绍的happens-before九大规则. 都是能够保证可见性的.其中就包含了锁操作(synchronized 和 lock) 和 volatile 修饰的变量https://javaweixin6.blog.csdn.net/article/details/108423590synchronized作用的升华synchronized 关键字

文章目录volatile的两点作用volatile与synchronized 的关系volatile总结volatile的两点作用保证可见性: 读取一个volatile 变量之前, 需要先使相应的本地缓存失效. 这样就必须到主内存读取最新的值,把读取到的最新的值, 放到子线程的工作内存中去. 写一个volatile 修饰的属性, 会立即刷入到主内存.禁止指令重排: 解决单例双重锁乱序问题.关于指令重排序,之前写的如下这篇文章中有提到指令重排序问题.https://javaweixin6.blo

文章目录volatile适用的场景:触发器volatile适用的场景:触发器volatile适用的场景:触发器. 用作刷新之前变量的触发器 .在这篇关于可见性这篇的文章中, 有如下的代码. 提到只用一个volatile就能保证a和b的可见性.https://javaweixin6.blog.csdn.net/article/details/108424008但是假如, 除了有变量a , 在b=0这个操作之前, 还有其他的很多变量, 例如下图的, abc abcd等变量. 那么在print方

文章目录volatile 修饰布尔的标记位volatile 修饰布尔适用的场景volatile 修饰布尔的标记位不适用的场景volatile 修饰布尔的标记位volatile 适用于 boolean flag 如果一个共享变量, 一直只被各个线程赋值, 而没有其他的操作, 那么就可以用volatile来代替synchronized 或者代替原子变量, 因为对布尔变量的赋值自身是有原子性的, 而volatile保证了可见性, 就满足了线程安全.因为布尔值, 只是改成true或者false, 具有原子

文章目录volatile介绍volatile 不适用的场景volatile介绍volatile是一种同步机制, 比synchronized 或者Lock 更轻量级, 因为使用volatile 并不会发生上下文切换等开销很大的行为. 仅仅是把值刷入主内存中, 和从主内存中读取值.如果一个变量被修饰成volatile , 那么JVM就这个了这个变量可能会被并发修改.由于volatile 开销小, 因此相应的并发能力也小, 虽然volatile 是用来同步保证线程安全性的, 但是volatile不能做到s

happens-before的使用案例如下的Java多线程 JMM之可见性demo文章中, 解决可见性方法使用的是两个volatilehttps://javaweixin6.blog.csdn.net/article/details/108419450主要是用于解决如下所示的第四种情况, 由于a的不可见性导致的.此时加一个volatile就能保证 a和b的可见性.b等于3的时候, a也一定是等于3的, 因为对于a的操作, 是由b的volatile保证可见的.b加了volatile之后,

文章目录happens-before所有规则1. 单线程规则2. 锁操作 (synchronized 和 lock)3.volatile 变量4.线程启动5. 线程join6. 传递性7.中断8. 构造方法9.并发工具类的happens-before原则happens-before所有规则单线程规则锁操作(synchronized 和 lock) 重点volatile 变量 重点线程启动线程join传递性中断构造方法并发工具类的happens-before原则线程安全的容器get

文章目录happens-before概念happens-before概念happens-before 的两种解释:happens-before 规则是用来解决可见性问题的, 在时间上, 动作A发生动作B之前, B保证一定能看到A, 这就是happens-before两个操作可以用happens-before 来确定执行顺序: 如果第一个操作happens-before于另外一个操作(即线程1先于线程2执行), 那么就可以说第一个操作相对于第二个操作是可见的(即线程2可以感知到线程1改变的变量

文章目录JMM抽象: 主内存和本地内存概念主内存和本地内存的关系JMM抽象: 主内存和本地内存概念JMM屏蔽了底层细节, 定义了一套读写内存数据的规范, 不再需要关心一级缓存二级缓存的问题,抽象了主内存和本地内存的概念.本地内存并不是真的给每一个线程分配内存, 而是JMM的一个抽象, 是对于寄存器, 一级缓存, 二级缓存 三级缓存的抽象.即下图中的这些缓存, 不用管独享的是哪一部分, 共享的是哪一部分. JMM帮我们抽象成了主内存和本地内存这两部分.如下图所示, 每一个Thread假设代表

文章目录可见性问题出现的原因可见性问题出现的原因主要的原因可以从下图中分析出来.此图中, 最下层为ram, 也就是内存, 而内存离CPU之间 ,是有多级的缓存的.L3 cache为内存的一部分, 会把内存中高频用到的部分缓存起来.L2 cache为L3 cache的一部分, 会把L3 cache高频用到的部分缓存起来.L1 cache为L2 cache的一部分, 会把L2 cache高频用到的部分缓存起来.每一层缓存的大小在缩小, 但读取速度在不断的增加.到了Register 是寄存器,

文章目录JMM之可见性demo可见性问题图解JMM之可见性demo如下的代码演示了可见性问题 . 一个线程调用给a 和b赋值的方法, 一个线程调用打印a和b的方法. 并进行循环的打印.package com.thread.jmm;/** * 类名称:FieldVisibility * 类描述: 演示可见性问题 * * @author: https://javaweixin6.blog.csdn.net/ * 创建时间:2020/9/5 14:31 * Version 1.0

文章目录重排序demo什么是重排序重排序的好处重排序的三种情况重排序demo如下的代码演示了重排序的发生情况.主要是有四个变量 xy ab .线程1 是对 a赋初始化值为1 , 把b的值给x .线程2 是给b赋初始化值为1 , 把a的值给ypackage com.thread.jmm;import java.util.concurrent.CountDownLatch;/** * 类名称:OutOfOrderExecution * 类描述: 演示重排序的现象 “直到达到某个条件才

文章目录为什么需要JMM什么是JMMJMM是并发工具类和并发关键字的底层原理关于JMM最重要的三点内容为什么需要JMM由于c语言是不存在内存模型的概念的. 因此它的执行是依赖于处理器的, 导致了不同的处理器的处理结果不一样, 也就无法保证并发安全.因此需要一个标准, 让多线程的运行结果达到可预期的状态. 不会再出现不同的处理器运行的结果不一致的情况.什么是JMMJMM : Java Memory ModelJMM 是一组规范, 需要各个JVM的实现来遵循JMM规范, 以便于开发者利用

文章目录整体方向上的区别JVM内存结构Java对象模型整体方向上的区别jvm内存结构: 和Java虚拟机的运行时区域有关.Java内存模型: 和Java的并发编程有关Java对象模型: 和Java对象在虚拟机中的表现形式有关.JVM内存结构Java代码是运行在jvm虚拟机上的, 并且分为了不同的区域.下图为jvm的运行时数据区:绿色的为线程共享的, 橙色的为线程对有的 .堆: 创建的对象和数组存放在此处, 也是jvm垃圾回收的主要区域.方法区: 存储已经加载的static