大型网站系统与Java中间件开发（曾宪杰）-持续更新

线程不安全的容器或者对象

线程安全的容器或者对象

子主题

两个锁A和B，两个线程T1和T2，T1和T2的某段代码都需要获取A和B的两个锁。

原子性的获取锁

调整对多个锁的获取顺序

一次性获取需要的全部锁

BIO即Blocking IO，采用阻塞的方式实现。

一个Socket套接字需要使用一个线程来进行处理。

图

优点

缺点

NIO即NonBlocking IO，基于事件驱动的方式，采用的Reactor模式

Reactor模式

 

优点

AIO即AsynchronousIO即异步IO。

AIO采用Proactor模式。

AIO与NIO的差别

在web服务中，处理web请求通常有两种体系结构

定义

工作方式&原理

Reactor模式也有三种不同的方式

定义

工作方式&原理

主动和被动

实现

优缺点

适用场景

坏处是增加了所需的配置

好处是每个数据库连接池的隔离。

坏处

好处

读写分离解决的是读压力大的问题，对于数据量大或者更新量大的情况病不起作用。

垂直拆分是把不同的表拆到不同的数据库中。

水平拆分是把同一个表拆到不同的数据库中。

此时如果新生的对象无法在 Eden 区创建（Eden 区无法容纳) 就会触发一次Young GC 此时会将 S0 区与Eden 区的对象一起进行可达性分析，找出活跃的对象，将它复制到 S1 区并且将S0区域和 Eden 区的对象给清空，这样那些不可达的对象进行清除，并且将S0 区 和 S1区交换。

但是这里会产生一个问题，Q:为啥会有两个 Survivor 区？
A: 因为假设设想一下只有一个 Survibor 区 那么就无法实现对于 S0 区的垃圾收集，以及分代年龄的提升。

子主题

java的关键字，在jvm层面上

是一个类

1、以获取锁的线程执行完同步代码，释放锁

2、线程执行发生异常，jvm会让线程释放锁

在finally中必须释放锁，不然容易造成线程死锁

假设A线程获得锁，B线程等待，

如果A线程阻塞，B线程会一直等待

分情况而定，lock有多个锁获取的方法，可以尝试获得锁，

线程可以不用功一直等待

无法判断

可以判断

少量同步

大量同步

synchronized是关键字，属于JVM层面，底层是由一对monitorenter和monitorexit指令实现的。

ReentrantLock是一个具体类，是API层面的锁。

synchronized不需要用户手动释放锁，当synchronized代码块执行完成后，系统会自动让线程释放对锁的占用

ReentrantLock需要用户手动释放锁，若没有手动释放可能导致死锁现象。

synchronized不可中断，除非抛出异常或者正常运行完成

ReentrantLock可中断

synchronized非公平锁

ReentrantLock两者都可以，默认是非公平锁。

synchronized没有。

ReentrantLock可用来分组唤醒需要唤醒的线程。而不是像synchronized要么随机唤醒一个线程，要么唤醒所有线程。

package com.yonghui.galaxy.metadata.juc;

import java.util.concurrent.locks.Condition;
import java.util.concurrent.locks.Lock;
import java.util.concurrent.locks.ReentrantLock;

/**
 *java面试-synchronized与lock有什么区别？
 *
 * https://www.cnblogs.com/wjh123/p/11129548.html
 *
 *
 * 1、原始构成：

 synchronized是关键字，属于JVM层面，底层是由一对monitorenter和monitorexit指令实现的。

 ReentrantLock是一个具体类，是API层面的锁。

 2、使用方法：

 synchronized不需要用户手动释放锁，当synchronized代码块执行完成后，系统会自动让线程释放对锁的占用

 ReentrantLock需要用户手动释放锁，若没有手动释放可能导致死锁现象。

 3、等待是否可中断：

 synchronized不可中断，除非抛出异常或者正常运行完成

 ReentrantLock可中断

 4、加锁是否公平：

 synchronized非公平锁

 ReentrantLock两者都可以，默认是非公平锁。

 5、锁绑定多个条件Condition：

 synchronized没有。

 ReentrantLock可用来分组唤醒需要唤醒的线程。而不是像synchronized要么随机唤醒一个线程，要么唤醒所有线程。

 题目：多线程之间按顺序调用，实现A->B->C三个线程启动，要求如下：

 * AA打印5次，BB打印10次，CC打印15次
 * 紧接着
 * AA打印5次，BB打印10次，CC打印15次
 * 来10轮
 */
public class TestLocknewCondition {

    public static void main(String[] args) {
        ShareResource shareResource = new ShareResource();
        new Thread(() -> {
            for (int i = 0; i < 10; i++) {
                shareResource.print5();
            }
        }, "AAA").start();

        new Thread(() -> {
            for (int i = 0; i < 10; i++) {
                shareResource.print10();
            }
        }, "BBB").start();

        new Thread(() -> {
            for (int i = 0; i < 10; i++) {
                shareResource.print15();
            }
        }, "CCC").start();
    }
}
class  ShareResource {
    private int number = 1;
    private Lock lock = new ReentrantLock();
    private Condition condition1 = lock.newCondition();
    private Condition condition2 = lock.newCondition();
    private Condition condition3 = lock.newCondition();

    public void print5() {
        lock.lock();
        try {
            while (number != 1) {
                condition1.await();
            }
            for (int i = 1; i <= 5; i++) {
                System.out.println(Thread.currentThread().getName() + " " + i);
            }
            number = 2;

            // 唤醒等待condition2的线程
            condition2.signal();// signal: 信号 ，指示
            /**
             * FIXME  java.util.concurrent.locks.Condition#signal()
             *唤醒一个正在等待的线程。
             *
             如果有任何线程在此条件下等待，则会选择一个线程进行唤醒。然后，该线程必须在从{@code wait}返回之前重新获取锁。
             *
             *实施注意事项</b>
             *
             *<p>调用此方法时，实现可能（并且通常确实）要求当前线程持有与此{@code Condition}关联的锁。您必须记录此先决条件以及未持有锁时所采取的任何操作。
             通常，会引发{@link IllegalMonitorStateException}之类的异常。
             */
        } catch (InterruptedException e) {
            e.printStackTrace();
        } finally {
            lock.unlock();
        }
    }


    public void print10() {
        lock.lock();
        try {
            while (number != 2) {
                condition2.await();
            }
            for (int i = 1; i <= 10; i++) {
                System.out.println(Thread.currentThread().getName() + " " + i);
            }
            number = 3;

            // 唤醒等待condition3的线程
            condition3.signal();
        } catch (InterruptedException e) {
            e.printStackTrace();
        } finally {
            lock.unlock();
        }
    }


    public void print15() {
        lock.lock();
        try {
            while (number != 3) {
                condition3.await();
            }
            for (int i = 1; i <= 15; i++) {
                System.out.println(Thread.currentThread().getName() + " " + i);
            }
            number = 1;
            // 唤醒等待condition1的线程
            condition1.signal();
        } catch (InterruptedException e) {
            e.printStackTrace();
        } finally {
            lock.unlock();
        }
    }
}

线程解锁前，必须把共享变量的最新值刷新到主内存中。

线程加锁时，将清空工作内存中共享变量的值，从而使用共享变量时需要从主内存中重新读取最新的值(注意：加锁和解锁需要同一把锁)。

获得互斥锁

清空工作内存

从主内存拷贝变量的最新副本到工作内存

执行代码

将更改后的共享变量的值刷新到主内存

释放互斥锁

深入来说：通过加入内存屏障和禁止重排序优化来实现的。

线程写volatile变量的过程：
写操作后加入一条store屏障指令。

线程读volatile变量的过程：
会在读操作后加入一条load屏障指令。

对于下面的一段程序的使用volatile和synchronized

private int number = 0;              

number++;//不是原子操作                   

1读取number的值                      

2将number的值加1                    

3写入最新的number的值  

//加入synchronized，变为原子操作   

synchronized(thhis){ 

        number++; 

}

//变为volatile变量，无法保证原子性

private volatile int number = 0;
————————————————
版权声明：本文为CSDN博主「我还是个少年」的原创文章，遵循CC 4.0 BY-SA版权协议，转载请附上原文出处链接及本声明。
原文链接：https://blog.csdn.net/a347911/article/details/88379625

volatile变量可用于提供线程安全，但是只能应用于非常有限的一组用例：多个变量之间或者某个变量的当前值与修改后值之间没有约束。因此，单独使用 volatile 还不足以实现计数器、互斥锁或任何具有与多个变量相关的不变式（Invariants）的类（例如 “start <=end”）。

出于简易性或可伸缩性的考虑，您可能倾向于使用 volatile 变量而不是锁。当使用 volatile 变量而非锁时，某些习惯用法（idiom）更加易于编码和阅读。此外，volatile 变量不会像锁那样造成线程阻塞，因此也很少造成可伸缩性问题。在某些情况下，如果读操作远远大于写操作，volatile 变量还可以提供优于锁的性能优势。
————————————————
版权声明：本文为CSDN博主「我还是个少年」的原创文章，遵循CC 4.0 BY-SA版权协议，转载请附上原文出处链接及本声明。
原文链接：https://blog.csdn.net/a347911/article/details/88379625

导致的问题

如何解决

一般只有在短时间内高并发的情况下才会出现变量得不到及时更新的情况，因为CPU在执行时会很快地刷新缓存，所以一般情况下很难看到这种问题。慢了不就不会刷新了。CPU运算快的话，在分配的时间片内就能完成所有工作：工作内从1->主内存->工作内存2，这样一来就保证了数据的可见性。在这个过程中，假如线程没有在规定时间内完成工作，然后这个线程就释放CPU，分配给其它线程，该线程就需要等待CPU下次给该线程分配时间片，如果在这段时间内有别的线程访问共享变量，可见性就没法保证了。
————————————————
版权声明：本文为CSDN博主「我还是个少年」的原创文章，遵循CC 4.0 BY-SA版权协议，转载请附上原文出处链接及本声明。
原文链接：https://blog.csdn.net/a347911/article/details/88379625

AtomicInteger

AtomicBoolean

AtomicLong

AtomicIntegerArray：整型数组原子类
AtomicLongArray：长整型数组原子类
AtomicReferenceArray ：引用类型数组原子类

基本类型原子类只能更新一个变量，如果需要原子更新多个变量，需要使用 引用类型原子类。

如果需要原子更新某个类里的某个字段时，需要用到对象的属性修改类型原子类。

假设两个线程访问同一变量x。

第一个线程获取到了变量x的值A，然后执行自己的逻辑。
这段时间内，第二个线程也取到了变量x的值A，然后将变量x的值改为B，然后执行自己的逻辑，最后又把变量x的值变为A【还原】。
在这之后，第一个线程终于进行了变量x的操作，但此时变量x的值还是A，因为x的值没有变化，所以compareAndSet还是会成功执行。
先来看一个值变量产生的ABA问题，理解一下ABA问题产生的流程：
@SneakyThrows
@Testpublic void test1() {    AtomicInteger atomicInteger = new AtomicInteger(10);
    CountDownLatch countDownLatch = new CountDownLatch(2);
    new Thread(() -> {
        atomicInteger.compareAndSet(10, 11);
        atomicInteger.compareAndSet(11,10);
        System.out.println(Thread.currentThread().getName() + "：10->11->10");
        countDownLatch.countDown();    }).start();    

new Thread(() -> {
        try {
            TimeUnit.SECONDS.sleep(1);
            boolean isSuccess = atomicInteger.compareAndSet(10,12);
            System.out.println("设置是否成功：" + isSuccess + ",设置的新值：" + atomicInteger.get());
        } catch (InterruptedException e) {
            e.printStackTrace();        }        
 countDownLatch.countDown();    }).start();    

countDownLatch.await();
}//输出：线程2并没有发现初始值已经被修改
//Thread-0：10->11->10
//设置是否成功：true,设置的新值：12

线程1和线程2并发访问ConcurrentStack。
线程1执行出栈【预期结果是弹出B，A成为栈顶】，但在读取栈顶B之后，被线程2抢占。
线程2记录栈顶B，依次弹出B和A，再依次将C，D，B入栈，且保证B就是原栈顶记录的B。
之后轮到线程1，发现栈顶确实是期望的B，虽弹出B，但此时栈顶已经是D，就出现了错误。

AtomicStampedReference 原子更新带有版本号的引用类型。该类将整数值与引用关联起来，可用于解决原子的更新数据和数据的版本号，可以解决使用 CAS 进行原子更新时可能出现的 ABA 问题。

而AtomicMarkableReference 通过标志位，标志位只有true和false，每次更新标志位的话，在第三次的时候，又会变得跟第一次一样，并不能解决ABA问题。