多线程讲解

曾经终败给现在 2022-02-02 09:29 180阅读 0赞

多线程讲解  
转载

有一点感触很深：很多人学多线程，并不是死在后面的volatile、ReentrantLock或者Executor线程池，而是最初期在“什么是锁”这个问题上迷糊了。

问题引申：  
什么是“锁”？  
“锁”到底长啥样？  
它锁定的是线程代码还是其他什么东西？

其实“锁”本身是个对象，synchronized这个关键字不是“锁”。硬要说的话，加synchronized仅仅是相当于“加锁”这个操作。

![在这里插入图片描述][watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3dlaXhpbl8zODI5NDk5OQ_size_16_color_FFFFFF_t_70]

![在这里插入图片描述][watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3dlaXhpbl8zODI5NDk5OQ_size_16_color_FFFFFF_t_70 1]

所以，所谓的加锁，严格意义上不是锁住代码块！如果这样想的话，后面很多问题就没法解释了。

概念：  
互斥的最基本条件是：共用同一把锁  
静态方法的锁是所在类的Class对象，普通方法的锁是this对象  
针对同一个线程，synchronized锁可以支持重入

下面通过几个小案例，加深上面三句话的理解

同一个类中的synchronized method m1和method m2互斥吗？  
思考下图：  
t1线程执行m1方法时要去读this对象锁，但是t2线程并不需要读锁，两者各管各的，没有交集（不共用一把锁）  
![在这里插入图片描述][watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3dlaXhpbl8zODI5NDk5OQ_size_16_color_FFFFFF_t_70 2]  
上图代码

public class C18  {
    
        public synchronized void m1(){
            System.out.println(Thread.currentThread().getName()+"m1 start....");
            try{
                Thread.sleep(10000);
            }catch (Exception a){
                a.printStackTrace();
            }
            System.out.println(Thread.currentThread().getName()+"m1 end");
        }
    
        public  void m2(){
            try{
                Thread.sleep(5000);
            }catch (Exception a){
                a.printStackTrace();
            }
            System.out.println(Thread.currentThread().getName()+"m2");
        }
    
        public static void main(String[] args) {
            C18 t = new C18();
    
            new Thread(t::m1,"t1").start();
            new Thread(t::m2,"t2").start();
        }
    
    }

第二个图  
同一个类中synchronized method m1中可以调用synchronized method m2吗？  
思考下图：  
synchronized是可重入锁，可以粗浅地理解为同一个线程在已经持有该锁的情况下，可以再次获取锁，并且会在某个状态量上做+1操作。  
![在这里插入图片描述][watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3dlaXhpbl8zODI5NDk5OQ_size_16_color_FFFFFF_t_70 3]  
上图代码

public class C18  {
    
        public synchronized void m1(){
            System.out.println("m1 start....");
            try{
                Thread.sleep(10000);
            }catch (Exception a){
                a.printStackTrace();
            }
            m2();
        }
    
        synchronized  void m2(){
            try{
                Thread.sleep(2000);
            }catch (Exception a){
                a.printStackTrace();
            }
            System.out.println("m2");
        }
        
    }

第三个图  
子类同步方法synchronized method m可以调用父类的synchronized method m吗（super.m()）？  
思考下图  
子类对象初始化前，会调用父类构造方法，在结构上相当于包裹了一个父类对象，用的都是this锁对象  
![在这里插入图片描述][watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3dlaXhpbl8zODI5NDk5OQ_size_16_color_FFFFFF_t_70 4]  
上图代码

public class C18  {
    
        public synchronized void m(){
            System.out.println("m start....");
            try{
                Thread.sleep(10000);
            }catch (Exception a){
                a.printStackTrace();
            }
            System.out.println("m end ");
        }
    
        public static void main(String[] args) {
            new TT().m();
        }
    
    }
    
    class TT extends C18 {
        @Override
       public synchronized void m(){
            System.out.println("chail m start....");
            super.m();
            System.out.println("chail m end ");
        }
    }

静态同步方法和非静态同步方法互斥吗？  
思考下图  
各玩各的，不是同一把锁，谈不上互斥  
![在这里插入图片描述][watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3dlaXhpbl8zODI5NDk5OQ_size_16_color_FFFFFF_t_70 5]

思考代码

public class C18 extends Thread {
    
        public synchronized void run(){
            System.out.println("run()1");
            try{
                Thread.sleep(5000);
            }catch (Exception a){
                System.out.println("cwu");
            }
            System.out.println("run()2");
        }
    
        public synchronized void A(){
            System.out.println("A");
            try{
                Thread.sleep(5000);
            }catch (Exception a){
                System.out.println("cwu");
            }
            System.out.println("A");
        }
    
        public static void main(String[] args) {
            C18 a = new C18();
            a.start();
            a.A();
        }
        
    }

运行结果  
![在这里插入图片描述][20190511092430963.png]  
一开始以为是synchronized是互相的，锁定的期间该方法无法被其他对象或者线程调用或启动，该线程无法调用或者启其他方法动直到synchronized区结束、但是，下面减了其中一个synchronized，却变成下面这样  
![在这里插入图片描述][20190511092524920.png]  
①请问synchronized是锁定对象还是线程，如果是线程的话，那么执行A（）synchronized锁定的应该是main线程吧，那还有Thread-0线程啊，为什么非要等A（）执行完，start才开始执行？

②为什么每次都是A（）先执行，是CPU分配的问题吗？

对上面所诉情况的 另外一种精简的解释  
synchronized锁的是对象，并且有三种情况：  
第一种是对于同步方法，即修饰某个函数，这个时候锁对象是当前类的实例化对象。  
第二种是对于同步静态方法，这个时候锁是当前类的Class对象。  
第三种就是后面跟括号，对于同步代码块,锁是括号里的对象。  
所以你这里锁定的是new出来的a对象。

至于为什么都是先打印“A”，是因为调用start()之后，a线程还只是由创建状态转为就绪状态，并没有进入运行状态（也就是还没调用run()），而这个时候main线程调用了a.A()，并且给a对象上锁了，所以后面run()要运行必须先等main线程释放a的锁，才能运行。而后面你去掉一个synchronized出现的情况就好解释了，因为main没有对a上锁，所以在打印第一个A之后那几秒钟内，a线程转为运行状态。

synchronize 的另外一种解释：

每个object有一个monitor，这东西其实就是个recursive lock，调用synchronized方法或者进入synchronized block的时候，当前thread就会尝试获取这个recursive lock，如果这个lock当前没有owner或者owner就是当前thread，则monitor的owner设为当前thread并且的锁定计数加一，否则当前thread就会一直等待到锁被释放，当退出sychronized block的时候锁定计数减一，减至0则释放锁。  
如果是static synchronized方法，锁定的对象是它所属的那个class，因为在JVM里class本身也是个对象。  
具体实现中可能有一些优化但原理上大致就是这么个东西。

锁的是对象，但只是在锁修饰的那个方法中检查对象是否被锁住，所以如果你都修饰就会按锁的顺序执行，如果有没有锁修饰的话就不会检查，锁住的就按照锁住的执行，没锁的就该怎么执行怎么执行。  
然后顺序的问题是因为你是用main线程执行A方法，子线程执行run方法，所以时间执行顺序就看它们谁执行的快，但一般main是直接继续执行，子线程还要从就绪转成运行状态，所以main线程会快一点。

[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3dlaXhpbl8zODI5NDk5OQ_size_16_color_FFFFFF_t_70]: /images/20220202/db28f1bb23c14bd1997eed9389156d36.png
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3dlaXhpbl8zODI5NDk5OQ_size_16_color_FFFFFF_t_70 1]: /images/20220202/04b0a9a3d55a4a00b8fe892ca9cc8171.png
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3dlaXhpbl8zODI5NDk5OQ_size_16_color_FFFFFF_t_70 2]: /images/20220202/06fd21049be04399bce755feb6ddbf30.png
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3dlaXhpbl8zODI5NDk5OQ_size_16_color_FFFFFF_t_70 3]: /images/20220202/bb7de8055d6743809b9909580b3c6378.png
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3dlaXhpbl8zODI5NDk5OQ_size_16_color_FFFFFF_t_70 4]: /images/20220202/0629d9797e974ac3bb1fb73102c26258.png
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3dlaXhpbl8zODI5NDk5OQ_size_16_color_FFFFFF_t_70 5]: /images/20220202/e0f8df555a4a4d93b4fe5fe27ac0b92a.png
[20190511092430963.png]: /images/20220202/f9b4867d46ab41c282a8e18e3acafbff.png
[20190511092524920.png]: /images/20220202/7f347dd235fd484a814ab78c08f65e9b.png