java 并发——内置锁

坚持学习,总会有一些不一样的东西。

一、由单例模式引入

引用一下百度百科的定义——
线程安全是多线程编程时的计算机程序代码中的一个概念。在拥有共享数据的多条线程并行执行的程序中,线程安全的代码会通过同步机制保证各个线程都可以正常且正确的执行,不会出现数据污染等意外情况。

文字定义总是很含糊,举个反例就很清楚了,想起之前总结过单例模式,就从单例模式开始吧。如果不清楚单例模式的新同学,可以看一下这篇总结:
java中全面的单例模式多种实现方式总结

单例模式中,懒汉式的实现方案如下:

public class Singleton {
    private Singleton() {
    }

    private static Singleton sSingleton;

    public static Singleton getInstance() {
        if (sSingleton == null) {
            sSingleton = new Singleton();
        }
        return sSingleton;
    }
}

该方法在单线程中运行是没有问题的,但是在多线程中,某些情况下,多个线程同时都判断到 sSingleton == null,然后又都执行 sSingleton = new Singleton(),这样就不能保证单例了,我们说它不是线程安全的。
一种改进方法:

public class Singleton {
    private Singleton() {
    }

    private static Singleton sSingleton;

    public synchronized static Singleton getInstance() {
        if (sSingleton == null) {
            sSingleton = new Singleton();
        }
        return sSingleton;
    }
}

上面这种实现,实际上效率非常低,是完全不推荐使用的。主要是因为加了 sychronized 关键字,意为同步的,也就是内置锁。使用 synchronized 关键字修饰方法, 是对该方法加锁,这样在同一时刻,只有一个线程能进入该方法,这样保证了线程安全,但是也正因为如此,效率变得很低,因为当对象创建之后,再次调用该方法的时候,直接使用对象就可以了,无需再同步了。于是有了下面改进的实现方式—— DCL(双重检查锁):

public class Singleton {
    private Singleton() {
    }

    /**
     * volatile is since JDK5
     */
    private static volatile Singleton sSingleton;

    public static Singleton getInstance() {
        if (sSingleton == null) {
            synchronized (Singleton.class) {
                // 未初始化,则初始instance变量
                if (sSingleton == null) {
                    sSingleton = new Singleton();
                }
            }
        }
        return sSingleton;
    }
}

sSingleton = new Singleton() 不是一个原子操作。故须加 volatile 关键字修饰,该关键字在 jdk1.5 之后版本才有。下面就来说说 synchronizedvolatile 这两个关键字。

二、同步与 synchronized

synchronized 锁代码块

java 提供了一种一种内置锁,来实现同步代码块,同步代码块包含两个部分:一个作为锁的对象引用,一个由锁保护的代码块。形式如下:

synchronized (lock) {
    // 由锁保护的代码块
}

每个 java 对象都可以作为实现同步的锁,java 的内置锁也称为互斥锁。同一时刻只能有一个线程获得该锁,获得该锁的线程才能进入由锁保护的代码块,其它线程只能等待该线程执行完代码块之后,释放该锁后,再去获得该锁。例子:

public class SynchronizedDemo1 {
    private Object lock = new Object();

    public static void main(String[] args) {
        SynchronizedDemo1 demo = new SynchronizedDemo1();
        new Thread(() -> {
            try {
                demo.test1();
            } catch (InterruptedException e) {
                e.printStackTrace();
            }
        }).start();
        try {
            demo.test1();
        } catch (InterruptedException e) {
            e.printStackTrace();
        }
    }

    public void test1() throws InterruptedException {
        System.out.println("--- test1 begin - current thread: " + Thread.currentThread().getId());
        Thread.sleep(1000);
        synchronized (lock) {
            System.out.println("--- test1 synchronized - current thread: " + Thread.currentThread().getId());
            Thread.sleep(5000);
        }
        System.out.println("--- test1 end - current thread: " + Thread.currentThread().getId());
    }
}

执行结果:

从结果可以清楚地看到一个线程进入同步代码块之后,另一个线程阻塞了,需要等到前者释放锁之后,它获得锁了才能进入同步代码块。

上面代码中,我们创建的 lock 对象作为锁。用 synchronized 修饰方法又是什么充当了锁呢?

synchronized 修饰方法

以关键字 synchronized 修饰的方法就是一种横跨挣个方法的同步代码块,其中该同步代码块的锁就是调用该方法的对象。

class A {
    public synchronized void a(){
        System.out.println("hello");
    }
}

等价于

class A {
    public void a(){
        synchronized(this) {
            System.out.println("hello");
        }
    }
}

静态方法用 类名.方法名 来调用,以关键字 synchronized 修饰的静态方法则以 Class 对象作为锁。

class A {
    public static synchronized void a(){
        System.out.println("hello");
    }
}

等价于

class A {
    public void a(){
        synchronized(A.class) {
            System.out.println("hello");
        }
    }
}

写个demo测试一下:

public class A {
    public static void main(String[] args) {
        A obj_a = new A();
        new Thread() {
            @Override
            public void run() {
                try {
                    obj_a.a();
                } catch (InterruptedException e) {
                    e.printStackTrace();
                }
            }
        }.start();

        new Thread() {
            @Override
            public void run() {
                try {
                    obj_a.b();
                } catch (InterruptedException e) {
                    e.printStackTrace();
                }
            }
        }.start();

        new Thread(){
            @Override
            public void run() {
                try {
                    A.c();
                } catch (InterruptedException e) {
                    e.printStackTrace();
                }
            }
        }.start();

        try {
            A.d();
        } catch (InterruptedException e) {
            e.printStackTrace();
        }
    }

    public synchronized void a() throws InterruptedException {
        System.out.println("--- begin a - current Thread " + Thread.currentThread().getId());
        Thread.sleep(8000);
        System.out.println("--- end a - current Thread " + Thread.currentThread().getId());
    }

    public synchronized void b() throws InterruptedException {
        System.out.println("--- begin b - current Thread " + Thread.currentThread().getId());
        Thread.sleep(8000);
        System.out.println("--- end b - current Thread " + Thread.currentThread().getId());
    }

    public synchronized static void c() throws InterruptedException {
        System.out.println("--- begin c - current Thread " + Thread.currentThread().getId());
        Thread.sleep(5000);
        System.out.println("--- end c - current Thread " + Thread.currentThread().getId());
    }

    public synchronized static void d() throws InterruptedException {
        System.out.println("--- begin d - current Thread " + Thread.currentThread().getId());
        Thread.sleep(5000);
        System.out.println("--- end d - current Thread " + Thread.currentThread().getId());
    }
}

运行结果如下:

可以看到,由于方法 a 和 方法 b 是同一个锁 obj_A,所以当某个线程执行其中一个方法是,其他线程也不能执行另一个方法。但是方法 c 是由 A.class 对象锁住的,执行方法 C 的线程与另外两个线程没有互斥关系。

对于某个类的某个特定对象来说,该类中,所有 synchronized 修饰的非静态方法共享同一个锁,当在对象上调用其任意 synchronized 方法时,此对象都被加锁,此时,其他线程调用该对象上任意的 synchronized 方法只有等到前一个线程方法调用完毕并释放了锁之后才能被调用。
而对于一个类中,所有 synchronized 修饰的静态方法共享同一个锁。

可重入锁

当某个线程请求一个由其他线程持有的锁时,发出请求的线程就会阻塞,然而,内置锁是可重入的,,如果某个线程试图获得一个已经由它自己持有的锁,那么这个请求就会成功。这也意味着获取锁的操作粒度是“线程”,而不是“调用”。当线程请求一个未被持有的锁时,jvm 将记下锁的持有者(即哪个线程),并获取该锁的计数值为 1 ,当同一个线程再次获取该锁时, jvm 将计数值递增,当线程退出同步代码块时,计数值将递减,当计数值为 0 时,将释放锁。

public class B {
    public static void main(String[] args) {
        B obj_B = new B();
        obj_B.b();
    }

    private synchronized void a(){
        System.out.println("---a");
    }

    private synchronized void b(){
        System.out.println("---b");
        a();
    }
}

执行上面这段代码,将输出

---b
---a

假设没有可重入的锁,对于对象 obj_B 来说,调用 b 方法时,线程将会持有 obj_B 这个锁,在方法 b 中调用方法 a 时,将会一直等待方法 b 释放锁,造成死锁的情况。

《Java 并发编程实战》 中举的可重入锁的例子:

public class Widget {
    public synchronized void doSomething() {
        ...
    }
}  

public class LoggingWidget extends Widget {
    public synchronized void doSomething() {
        System.out.println(toString() + ": calling doSomething");
        super.doSomething();
    }
}

我第一遍看这段代码的时候,在思考,这里父类子类的方法都有synchronized同步,当调用子类LoggingWidget的doSomething()时锁对象肯定是当时调用的那个LoggingWidget实例,可是问题是当执行到super.doSomething()时,要调用父类的同步方法,那此时锁对象是谁?是同一个锁进入了 2 次,还是获得了子类对象和父类对象的 2 个不同的锁?
下面这段代码能给出结论:

public class Test {
  public static void main(String[] args) throws InterruptedException {
    final TestChild t = new TestChild();

    new Thread(new Runnable() {
      @Override
      public void run() {
        t.doSomething();
      }
    }).start();
    Thread.sleep(100);
    t.doSomethingElse();
  }

  public synchronized void doSomething() {
    System.out.println("something sleepy!");
    try {
      Thread.sleep(1000);
      System.out.println("woke up!");
    }
    catch (InterruptedException e) {
      e.printStackTrace();
    }
  }

  private static class TestChild extends Test {
    public void doSomething() {
      super.doSomething();
    }

    public synchronized void doSomethingElse() {
      System.out.println("something else");
    }
  }
}

这段代码输出了:

something sleepy!
woke up!
something else

而不是

something sleepy!
something else
woke up!

这说明是同一个锁进入了 2 次,即调用子类方法的子类对象。而这也正好符合多态的思想,调用 super.doSomething() 方法时,是子类对象调用父类方法。

三、同步关键字 volatile

原子性

原子是世界上的最小单位,具有不可分割性。 比如 a=0 这个操作不可分割,我们说这是一个原子操作。而 ++i 就不是一个原子操作。它包含了"读取-修改-写入"的操作。

同步代码块,可以视作是一个原子操作。Java从JDK 1.5开始提供了java.util.concurrent.atomic包,这个包中的原子操作类提供了一种用法简单、性能高效、线程安全地更新一个变量的方式。比如:AtomicBoolean AtomicInteger AtomicLong 等原子操作类。具体可查阅JDK源码或者参考《ava并发编程的艺术》第7章。

下面说说复合操作与线程安全的问题。
然后说说复合操作与线程安全的问题。
我们知道,java 集合框架中的 Vector 类是线程安全的,查看该类的源码发现,很多关键方法都用了synchronized 加以修饰。但是实际使用时候,稍有不慎,你会发现,它可能并不是线程安全的。比如在某个类中拓展一下 Vector 的方法,往 vector 中添加一个元素时,先判断该元素是否存在,如果不存在才添加,该方法大概像下面这样:

public class CJUtil{
    public void putElement(Vector<E> vector, E x){
        boolean has = vector.contains(x);
        if(!has){
            vector.add(x);
        }
    }
}

上面这个代码肯定是线程不安全的,但是为什么呢?不是说好,Vector 类是线程安全的吗?上网搜了一下,居然发现关于 Vector 类是不是线程安全的存在争议,然后我看到有人说它不是线程安全的,给出的理由比如像上面这种先判断再添加,或者先判断再删除,是一种复合操作,然后认真地打开 JDK 的源码看了,发现 Vector 类中 contains 方法并没有用 synchronized 修饰,然后得出了结论,Vector不是线程安全的...

事实到底是怎样的呢?我们假设 Vector 类的 contains 也用 synchronized 关键字加锁同步了,此时有两个线程 tA 和 tB 同时访问这个方法,tA 调用到 contains 方法的时候,tB 阻塞, tA 执行完 contains 方法,返回 false 后,释放了锁,在 tA 执行 add 之前,tB 抢到了锁,执行了 contains 方法,tA 阻塞。对于同一个元素, tb 判断也不包含,后面, tA 和 tB 都向 Vector 添加了这个元素。经过分析,我们发现,对于上述复合操作线程不安全的原因,并非是其中单个操作没有加锁同步造成的。

那如何解决这个问题呢?可能马上会想到,给 putElement 方法加上 synchronized 同步。

public class CJUtil{
    public synchronized void putElement(Vector<E> vector, E x){
        boolean has = vector.contains(x);
        if(!has){
            vector.add(x);
        }
    }
}

这样整个方法视为一个原子操作,只有当 tA 执行完整个方法后,tB 才能进入,也就不存在上面说的问题了。其实,这只是假象。这种在加锁的方法,并不能保证线程安全。我们可以从两个方面来分析一下:

  1. 从上文我们知道,给方法加锁,锁对象,是调用该方法的对象。这和我们操作 Vector 方法的锁并不是同一个锁。我们虽然保证了只有一个线程能够进入到 putElement 方法去操作 vector,但是我们没法保证其它线程通过其它方法不去操作这个 vector 。
  2. 上一条中,只有一个线程能够进入到 putElement 方法,是不准确的,因为这个方法不是静态的,如果在两个线程中,分别用 CJUtil 的两个不同的实例对象,是可以同时进入到 putElement 方法的。

    正确的做法应该是:
public class CJUtil{
    public void putElement(Vector<E> vector, E x){
        synchronized(vector){
            boolean has = vector.contains(x);
            if(!has){
                vector.add(x);
            }
        }
    }
}

重排序

重排序通常是编译器或运行时环境为了优化程序性能而采取的对指令进行重新排序执行的一种手段。重排序分为两类:编译器重排序和运行期重排序,分别对应编译时和运行时环境。

不要假设指令执行的顺序,因为根本无法预知不同线程之间的指令会以何种顺序执行。

编译器重排序的典型就是通过调整指令顺序,在不改变程序语义的前提下,尽可能的减少寄存器的读取、存储次数,充分复用寄存器的存储值。

int a = 5;① int b = 10;② int c = a + 1;③ 假设用的同一个寄存器

这三条语句,如果按照顺序一致性,执行顺序为①②③寄存器要被读写三次;但为了降低重复读写的开销,编译器会交换第二和第三的位置,即执行顺序为①③②

可见性

可见性是一种复杂的属性,因为可见性中的错误总是会违背我们的直觉。通常,我们无法确保执行读操作的线程能适时地看到其他线程写入的值,有时甚至是根本不可能的事情。为了确保多个线程之间对内存写入操作的可见性,必须使用同步机制。

可见性,是指线程之间的可见性,一个线程修改的状态对另一个线程是可见的。也就是一个线程修改的结果。另一个线程马上就能看到。比如:用volatile修饰的变量,就会具有可见性。volatile修饰的变量不允许线程内部缓存和重排序,即直接修改内存。所以对其他线程是可见的。但是这里需要注意一个问题,volatile只能让被他修饰内容具有可见性,但不能保证它具有原子性。
下面这段代码:

public class A {
    private static boolean flag = false;

    public static void main(String[] args) {
        new Thread() {
            @Override
            public void run() {
                while (!flag) {
                }
            }
        }.start();

        try {
            Thread.sleep(1000);
        } catch (InterruptedException e) {
            e.printStackTrace();
        }

        flag = true;
    }
}

看执行结果:

可以看到程序并没有像我们所期待的那样,在一秒之后,退出,而是一直处于循环中。
下面给 flag 加上 volatile 关键修饰:

public class A {
    private static volatile boolean flag = false;

    public static void main(String[] args) {
        new Thread() {
            @Override
            public void run() {
                while (!flag) {
                }
            }
        }.start();

        try {
            Thread.sleep(1000);
        } catch (InterruptedException e) {
            e.printStackTrace();
        }

        flag = true;
    }
}

再看结果:

结果表明,没有用 volatile 修饰 flag 之前,改变了不具有可见性,一个线程将它的值改变后,另一个线程却 “不知道”,所以程序没有退出。当把变量声明为 volatile 类型后,编译器与运行时都会注意到这个变量是共享的,因此不会将该变量上的操作与其他内存操作一起重排序。volatile 变量不会被缓存在寄存器或者对其他处理器不可见的地方,因此在读取volatile类型的变量时总会返回最新写入的值。

在访问volatile变量时不会执行加锁操作,因此也就不会使执行线程阻塞,因此volatile变量是一种比sychronized关键字更轻量级的同步机制。

当对非 volatile 变量进行读写的时候,每个线程先从内存拷贝变量到CPU缓存中。如果计算机有多个CPU,每个线程可能在不同的CPU上被处理,这意味着每个线程可以拷贝到不同的 CPU cache 中。

而声明变量是 volatile 的,JVM 保证了每次读变量都从内存中读,跳过 CPU cache 这一步。

volatile 修饰的遍历具有如下特性:

  1. 保证此变量对所有的线程的可见性,当一个线程修改了这个变量的值,volatile 保证了新值能立即同步到主内存,以及每次使用前立即从主内存刷新。但普通变量做不到这点,普通变量的值在线程间传递均需要通过主内存(详见:Java内存模型)来完成。
  2. 禁止指令重排序优化。
  3. 不会阻塞线程。

synchronized 与可见性

细心的人应该发现了,上面代码中的循环是一个空循环,我试着去掉 volatile 关键字,在循环里面加了一条打印信息,如下:

public class A {
    private static boolean flag = false;

    public static void main(String[] args) {
        new Thread() {
            @Override
            public void run() {
                while (!flag) {
                    System.out.println("---");
                }
            }
        }.start();

        try {
            Thread.sleep(1000);
        } catch (InterruptedException e) {
            e.printStackTrace();
        }

        flag = true;
    }
}

结果会是怎样,会一直打印 "---" 吗?看结果:

奇怪了,为什么没有使用 volatile 关键字,一秒之后程序也推出了。点击查看 System.out.println(String x) 的源码:

    public void println(String x) {
        synchronized (this) {
            print(x);
            newLine();
        }
    }

我们发现,该方法加锁同步了。

那么问题来了,synchronized 到底干了什么。。

按理说,synchronized 只会保证该同步块中的变量的可见性,发生变化后立即同步到主存,但是,flag 变量并不在同步块中,实际上,JVM对于现代的机器做了最大程度的优化,也就是说,最大程度的保障了线程和主存之间的及时的同步,也就是相当于虚拟机尽可能的帮我们加了个volatile,但是,当CPU被一直占用的时候,同步就会出现不及时,也就出现了后台线程一直不结束的情况。

参考书籍:
《Java 并发编程实战》
《Java 编程思想 第四版》

原文地址:https://www.cnblogs.com/joy99/p/9874589.html

时间: 2024-09-29 22:52:17

java 并发——内置锁的相关文章

Java 并发:内置锁 Synchronized

摘要: 在多线程编程中,线程安全问题是一个最为关键的问题,其核心概念就在于正确性,即当多个线程访问某一共享.可变数据时,始终都不会导致数据破坏以及其他不该出现的结果.而所有的并发模式在解决这个问题时,采用的方案都是序列化访问临界资源 .在 Java 中,提供了两种方式来实现同步互斥访问:synchronized 和 Lock.本文针对 synchronized 内置锁 详细讨论了其在 Java 并发 中的应用,包括它的具体使用场景(同步方法.同步代码块.实例对象锁 和 Class 对象锁).可重

转:【Java并发编程】之一:可重入内置锁

每个Java对象都可以用做一个实现同步的锁,这些锁被称为内置锁或监视器锁.线程在进入同步代码块之前会自动获取锁,并且在退出同步代码块时会自动释放锁.获得内置锁的唯一途径就是进入由这个锁保护的同步代码块或方法. 当某个线程请求一个由其他线程持有的锁时,发出请求的线程就会阻塞.然而,由于内置锁是可重入的,因此如果摸个线程试图获得一个已经由它自己持有的锁,那么这个请求就会成功."重入"意味着获取锁的操作的粒度是"线程",而不是调用.重入的一种实现 方法是,为每个锁关联一个

《java并发编程实战》读书笔记1--线程安全性,内置锁,重入,状态

什么是线程安全? 当多个线程访问某个类时,不管这些的线程的执行顺序如何,并且在主调代码中不需要任何额外的同步或协同,这个类都能表现出正确的行为,那么就称这个类是线程安全的. 哈哈书上的解释,还是翻译过来的,看了半天还是觉得有点奇怪.比如说 "类都能表现出正确的行为" 是毛线意思?在网上搜了一番 "线程安全就是说多线程访问同一代码,不会产生不确定的结果" 这样反而跟容易理解,果然读书要么读原版中文书要么读原版英文书,看英文的翻译版真的是蛋疼无比.说到这里,我以前貌似把

Java并发编程(1):可重入内置锁

每个Java对象都可以用做一个实现同步的锁,这些锁被称为内置锁或监视器锁.线程在进入同步代码块之前会自动获取锁,并且在退出同步代码块时会自动释放锁.获得内置锁的唯一途径就是进入由这个锁保护的同步代码块或方法. 当某个线程请求一个由其他线程持有的锁时,发出请求的线程就会阻塞.然而,由于内置锁是可重入的,因此如果摸个线程试图获得一个已经由它自己持有的锁,那么这个请求就会成功."重入"意味着获取锁的操作的粒度是"线程",而不是调用.重入的一种实现方法是,为每个锁关联一个获

jvm内置锁synchronized不能被中断

很久没看技术书籍了,今天看了一下<七周七并发模型>前面两章讲的java,写的还是有深度的.看到了一个有demo,说jvm内置锁synchronized是不能被中断的.照着书上写了个demo,验证了一下,是不能被中断 /** * @Author: * @Description: jdk内置锁不能被中断 * @Date: Created in : 2018/10/4 下午11:34 **/ public class Uninterruptible { private static final Ob

012 内置锁和synchronized

一 . 概述 在前面我们说到线程安全性问题解决的核心就是同步,同步的核心就是保证原子性. 在java之中最早就支持语法层面的同步解决了,并且提供了synchronized的方式解决问题. 二 .内置锁 在java之中每一个对象都是一个内置锁,这个在JVM的体系之中就规定好了. 内置锁的规定也就决定我们可以拿任意的对象进行同步操作. 内置锁常常配合synchronized使用. 三 .synchronized 该关键词的作用是同步,需要配合内置锁进行使用. 常见的synchronized的使用方式

使用ReentrantLock和Condition来代替内置锁和wait(),notify(),notifyAll()

使用ReentrantLock可以替代内置锁,当使用内置锁的时候,我们可以使用wait() nitify()和notifyAll()来控制线程之间的协作,那么,当我们使用ReentrantLock的时候,我们怎么来处理线程之间的写作呢? JDK5.0为我们提供了Condition对象来替代内置锁的 wait(),notify()和notifyAll()方法 内置锁的话,就只能有一个等待队列,所有的在某个对象上执行wait()方法的线程都会被加入到该对象的等待队列中去(线程会被挂起),需要其他的线

Java并发编程:锁的释放

.title { text-align: center } .todo { font-family: monospace; color: red } .done { color: green } .tag { background-color: #eee; font-family: monospace; padding: 2px; font-size: 80%; font-weight: normal } .timestamp { color: #bebebe } .timestamp-kwd

内置锁(二)synchronized下的等待通知机制

一.等待/通知机制的简介 线程之间的协作: ??为了完成某个任务,线程之间需要进行协作,采取的方式:中断.互斥,以及互斥上面的线程的挂起.唤醒:如:生成者--消费者模式.或者某个动作完成,可以唤醒下一个线程.管道流已准备等等: 等待/通知机制: ? ?等待/通知机制 是线程之间的协作一种常用的方式之一,在显示锁Lock 和 内置锁synchronized都有对应的实现方式. 等待/通知机制 经典的使用方式,便是在生产者与消费者的模式中使用: 1.生产者负责生产商品,并送到仓库中存储: 2.消费者