锁

锁

锁升级过程

锁的状态总共有四种，级别由低到高依次为：无锁、偏向锁、轻量级锁、重量级锁，
这四种锁状态分别代表什么，为什么会有锁升级？
其实在 JDK 1.6之前，synchronized 还是一个重量级锁，是一个效率比较低下的锁，但是在JDK 1.6后，Jvm为了提高锁的获取与释放效率对（synchronized ）进行了优化，引入了 偏向锁 和 轻量级锁 ，从此以后锁的状态就有了四种（无锁、偏向锁、轻量级锁、重量级锁），
并且四种状态会随着竞争的情况逐渐升级，而且是不可逆的过程，即不可降级，也就是说只能进行锁升级（从低级别到高级别），不能锁降级（高级别到低级别），意味着偏向锁升级成轻量级锁后不能降级成偏向锁。
这种锁升级却不能降级的策略，目的是为了提高获得锁和释放锁的效率。

具体过程

1、线程A在进入同步代码块前，先检查MarkWord中的线程ID是否与当前线程ID一致，如果一致（还是线程A获取锁对象），则无需使用CAS来加锁、解锁。
2、如果不一致，再检查是否为偏向锁，如果不是，则自旋等待锁释放。
3、如果是，再检查该线程是否存在（偏向锁不会主动释放锁），如果不在，则设置线程ID为线程A的ID，此时依然是偏向锁。
4、如果还在，则暂停该线程，同时将锁标志位设置为00即轻量级锁（将MarkWord复制到该线程的栈帧中并将MarkWord设置为栈帧中锁记录）。线程A自旋等待锁释放。
5、如果自旋次数到了该线程还没有释放锁，或者该线程还在执行，线程A还在自旋等待，这时又有一个线程B过来竞争这个锁对象，那么这个时候轻量级锁就会膨胀为重量级锁。重量级锁把除了拥有锁的线程都阻塞，防止CPU空转。
6、如果该线程释放锁，则会唤醒所有阻塞线程，重新竞争锁。

https://www.cnblogs.com/mingyueyy/p/13054296.html

JVM锁优化和膨胀过程

1. 自旋锁：自旋锁其实就是在拿锁时发现已经有线程拿了锁，自己如果去拿会阻塞自己，这个时候会选择进行一次忙循环尝试。也就是不停循环看是否能等到上个线程自己释放锁。自适应自旋锁指的是例如第一次设置最多自旋10次，结果在自旋的过程中成功获得了锁，那么下一次就可以设置成最多自旋20次。
2. 锁粗化：虚拟机通过适当扩大加锁的范围以避免频繁的拿锁释放锁的过程。
3. 锁消除：通过逃逸分析发现其实根本就没有别的线程产生竞争的可能（别的线程没有临界量的引用），或者同步块内进行的是原子操作，而“自作多情”地给自己加上了锁。有可能虚拟机会直接去掉这个锁。
4. 偏向锁：在大多数的情况下，锁不仅不存在多线程的竞争，而且总是由同一个线程获得。因此为了让线程获得锁的代价更低引入了偏向锁的概念。偏向锁的意思是如果一个线程获得了一个偏向锁，如果在接下来的一段时间中没有其他线程来竞争锁，那么持有偏向锁的线程再次进入或者退出同一个同步代码块，不需要再次进行抢占锁和释放锁的操作。
5. 轻量级锁：当存在超过一个线程在竞争同一个同步代码块时，会发生偏向锁的撤销。当前线程会尝试使用CAS来获取锁，当自旋超过指定次数(可以自定义)时仍然无法获得锁，此时锁会膨胀升级为重量级锁。
6. 重量级锁：重量级锁依赖对象内部的monitor锁来实现，而monitor又依赖操作系统的MutexLock（互斥锁）。当系统检查到是重量级锁之后，会把等待想要获取锁的线程阻塞，被阻塞的线程不会消耗CPU，但是阻塞或者唤醒一个线程，都需要通过操作系统来实现。

synchronized

Java的一个关键字，能够将代码块锁起来
是一种互斥锁，一次只能允许一个线程进入被锁住的代码块

Java中每一个对象都可以作为锁，这是synchronized实现同步的基础//objectMonitor

本质是保护资源

synchronized 代码块是由一对儿 monitorenter/monitorexit 指令实现的，Monitor 对象是同步的基本实现，
而 synchronized 同步方法使用了ACC_SYNCHRONIZED访问标志来辨别一个方法是否声明为同步方法，从而执行相应的同步调用

锁的种类

修饰普通方法：锁是当前实例对象

修饰静态方法：锁是当前类的class对象

• synchronized应用在static方法上，那是对当前对应的*.Class进行持锁
• synchronized(*.class)代码块的作用其实和synchronized static方法作用一样。Class锁对类的所有对象实例起作用

修饰代码块

• synchronized (this)代码块是锁定当前对象
• synchronized(Object)多个线程持有对象监视器作为同一个对象的前提下，同一时间只有一个线程可以执行同步代码块

获取了类锁的线程和获取了对象锁的线程是不冲突的，不互斥

锁的释放

当方法/代码块执行完毕会自动释放锁，不需要做任何的操作

当一个线程执行的代码出现异常时，其所持有的锁会自动释放

自旋锁

线程的阻塞和唤醒需要CPU从用户态转变为内核态，频繁的阻塞和唤醒对CPU来说是一件负担很重的工作，同时我们发现许多应用，对象锁的锁状态只会持续很短一段时间，所以引入自旋锁

让该线程等待一段时间，不会被立即挂起

Jdk1.6默认开启，自旋默认的次数为10次

适应自旋锁

阻塞锁

多个线程进入阻塞状态进行等待，当获得相应的唤醒信号时，才唤醒

乐观锁CAS

CAS是英文单词CompareAndSwap的缩写，中文意思是：比较并替换。CAS需要有3个操作数：内存地址V，旧的预期值A，即将要更新的目标值B。

CAS指令执行时，当且仅当内存地址V的值与预期值A相等时，将内存地址V的值修改为B，否则就什么都不做。整个比较并替换的操作是一个原子操作。

jdk1.6 之后synchronized优化
CAS，乐观锁技术

CAS和轻量锁是同时发生的
重量锁之前都是无锁，偏向，自旋，轻量都是一种关于锁策略的标记

ABA，本来是A，修改成B，又修改成A，加个版本号或时间戳

普通对象构成：
markword：分代信息、偏向锁指向，锁标志位，后3个字节
类型指针
实例数据
每次自增都进行加锁，性能可能会稍微差了点，有更好的方案吗？

CAS的缺点：
CAS虽然很高效的解决了原子操作问题，但是CAS仍然存在三大问题。
. 循环时间长开销很大。
. 只能保证一个变量的原子操作。
. ABA问题。

锁消除

JVM检测到不可能存在共享数据竞争，就会对同步锁进行锁消除

lock/ReentrantLock/重入锁

可以try/lock直接返回获取成功或者失败，线程不用一直等待，在finally中必须要释放该锁

ReentrantLock lock = new ReentrantLock();

        for (int i = 1; i <= 3; i++) {
            lock.lock();
        }

        for(int i=1;i<=3;i++){
            try {

            } finally {
                lock.unlock();
            }
        }

ReentrantLock是可以重入的锁,当一个线程获取锁时,还可以接着重复获取多次。在加上ReentrantLock的的独占性

ReentrantLock和synchronized的相同点

ReentrantLock和synchronized都是独占锁,只允许线程互斥的访问临界区。但是实现上两者不同:synchronized加锁解锁的过程是隐式的,用户不用手动操作,优点是操作简单，但显得不够灵活。一般并发场景使用synchronized的就够了；ReentrantLock需要手动加锁和解锁,且解锁的操作尽量要放在finally代码块中,保证线程正确释放锁。ReentrantLock操作较为复杂，但是因为可以手动控制加锁和解锁过程,在复杂的并发场景中能派上用场。

ReentrantLock和synchronized都是可重入的。synchronized因为可重入因此可以放在被递归执行的方法上,且不用担心线程最后能否正确释放锁；而ReentrantLock在重入时要却确保重复获取锁的次数必须和重复释放锁的次数一样，否则可能导致其他线程无法获得该锁。

公平锁是指当锁可用时,在锁上等待时间最长的线程将获得锁的使用权。而非公平锁则随机分配这种使用权。和synchronized一样，默认的ReentrantLock实现是非公平锁,因为相比公平锁，非公平锁性能更好。当然公平锁能防止饥饿,某些情况下也很有用

可重入锁：可以再次进入方法A，就是说在释放锁前此线程可以再次进入方法A（方法A递归）

广义上的可重入锁指的是可重复可递归调用的锁，在外层使用锁之后，在内层仍然可以使用，并且不发生死锁（前提得是同一个对象或者class），这样的锁就叫做可重入锁。ReentrantLock和synchronized都是可重入锁

重入锁实现可重入性原理或机制是：每一个锁关联一个线程持有者和计数器，当计数器为 0 时表示该锁没有被任何线程持有，那么任何线程都可能获得该锁而调用相应的方法；当某一线程请求成功后，JVM会记下锁的持有线程，并且将计数器置为 1；此时其它线程请求该锁，则必须等待；而该持有锁的线程如果再次请求这个锁，就可以再次拿到这个锁，同时计数器会递增；当线程退出同步代码块时，计数器会递减，如果计数器为 0，则释放该锁

当如果一个线程获得了对象锁，进入了同步块，其他访问该同步块的线程都必须阻塞在同步块外面等待，等到释放掉锁或者唤醒后才能继续获得锁

不可重入锁
不可重入锁，与可重入锁相反，不可递归调用，递归调用就发生死锁

Synchronized和Lock的区别

1. 首先synchronized是java内置关键字在jvm层面，Lock是个java类。
2. synchronized无法判断是否获取锁的状态，Lock可以判断是否获取到锁，并且可以主动尝试去获取锁。
3. synchronized会自动释放锁(a 线程执行完同步代码会释放锁 ；b 线程执行过程中发生异常会释放锁)，Lock需在finally中手工释放锁（unlock()方法释放锁），否则容易造成线程死锁。
4. 用synchronized关键字的两个线程1和线程2，如果当前线程1获得锁，线程2线程等待。如果线程1阻塞，线程2则会一直等待下去，而Lock锁就不一定会等待下去，如果尝试获取不到锁，线程可以不用一直等待就结束了。
5. synchronized的锁可重入、不可中断、非公平，而Lock锁可重入、可判断、可公平（两者皆可）
6. Lock锁适合大量同步的代码的同步问题，synchronized锁适合代码少量的同步问题。

AQS理论的数据结构

AQS内部有3个对象，一个是state（用于计数器，类似gc的回收计数器），一个是线程标记（当前线程是谁加锁的），一个是阻塞队列。

AQS是自旋锁，在等待唤醒的时候，经常会使用自旋的方式，不停地尝试获取锁，直到被其他线程获取成功。

AQS有两个队列，同步对列和条件队列。同步队列依赖一个双向链表来完成同步状态的管理，当前线程获取同步状态失败后，同步器会将线程构建成一个节点，并将其加入同步队列中。通过signal或signalAll将条件队列中的节点转移到同步队列。

sleep 和 wait 的区别

• sleep 方法是 Thread 类中的静态方法，wait 是 Object 类中的方法
• sleep 并不会释放同步锁，而 wait 会释放同步
• 锁sleep 可以在任何地方使用，而 wait 只能在同步方法或者同步代码块中使用
• sleep 中必须传入时间，而 wait 可以传，也可以不传，不传时间的话只有 notify 或者 notifyAll 才能唤醒，传时间的话在时间之后会自动唤醒

join的用法，内部实现wait(0)

join方法通常是保证线程间顺序调度的一个方法，它是 Thread 类中的方法。比方说在线程 A 中执行线程 B.join()，这时线程 A 会进入等待状态，直到线程 B 执行完毕之后才会唤醒，继续执行A线程中的后续方法。join 方法可以传时间参数，也可以不传参数，不传参数实际上调用的是 join(0)。它的原理其实是使用了 wait 方法，join 的原理如下

当Thread die的时候，会执行notifyAll

public final synchronized void join(long millis)
    throws InterruptedException {
        long base = System.currentTimeMillis();
        long now = 0;
        if (millis < 0) {
            throw new IllegalArgumentException("timeout value is negative");
        }
        if (millis == 0) {
            while (isAlive()) {
                wait(0);
            }
        } else {
            while (isAlive()) {
                long delay = millis - now;
                if (delay <= 0) {
                    break;
                }
                wait(delay);
                now = System.currentTimeMillis() - base;
            }
        }
    }
复制代码

两个进程同时要求写或者读，能不能实现？如何防止进程的同步？

线程间操作List

Java中对象的生命周期

Synchronized用法

synchronize的原理

谈谈对Synchronized关键字，类锁，方法锁，重入锁的理解

static synchronized 方法的多线程访问和作用

同一个类里面两个synchronized方法，两个线程同时访问的问题

volatile的原理

禁止指令重排序
保证被volatile修饰的变量对所有线程都是可见的
被volatile修饰的变量在工作内存修改后会被强制写回主内存，其他线程在使用时也会强制从主内存刷新，这样就保证了一致性

谈谈volatile关键字的用法

谈谈volatile关键字的作用

谈谈NIO的理解

1、面向流与面向缓冲

Java IO和NIO之间第一个最大的区别是，IO是面向流的，NIO是面向缓冲区的。

Java IO面向流意味着每次从流中读一个或多个字节，直至读取所有字节，它们没有被缓存在任何地方。此外，它不能前后移动流中的数据。如果需要前后移动从流中读取的数据，需要先将它缓存到一个缓冲区。

Java NIO面向缓冲区的缓冲导向方法略有不同。数据读取到一个它稍后处理的缓冲区，需要时可在缓冲区中前后移动。这就增加了处理过程中的灵活性。但是，还需要检查是否该缓冲区中包含所有您需要处理的数据。而且，需确保当更多的数据读入缓冲区时，不要覆盖缓冲区里尚未处理的数据。

2、阻塞与非阻塞IO

Java IO的各种流是阻塞的。这意味着，当一个线程调用read() 或 write()时，该线程被阻塞，直到有一些数据被读取，或数据完全写入。该线程在此期间不能再干任何事情了。

Java NIO的非阻塞模式，使一个线程从某通道发送请求读取数据，但是它仅能得到目前可用的数据，如果目前没有数据可用时，就什么都不会获取，而不是保持线程阻塞，所以直至数据变的可以读取之前，该线程可以继续做其他的事情。 非阻塞写也是如此。一个线程请求写入一些数据到某通道，但不需要等待它完全写入，这个线程同时可以去做别的事情。 线程通常将非阻塞IO的空闲时间用于在其它通道上执行IO操作，所以一个单独的线程现在可以管理多个输入和输出通道（channel）。

3、选择器（Selectors）

Java NIO的选择器允许一个单独的线程来监视多个输入通道，你可以注册多个通道使用一个选择器，然后使用一个单独的线程来“选择”通道：这些通道里已经有可以处理的输入，或者选择已准备写入的通道。这种选择机制，使得一个单独的线程很容易来管理多个通道。

synchronized 和volatile 关键字的区别

synchronized与Lock的区别

ReentrantLock 、synchronized和volatile比较

ReentrantLock的内部实现

lock原理

死锁的四个必要条件？

产生死锁的原因主要是：
（1） 因为系统资源不足。
（2） 进程运行推进的顺序不合适。
（3） 资源分配不当等。
如果系统资源充足，进程的资源请求都能够得到满足，死锁出现的可能性就很低，否则
就会因争夺有限的资源而陷入死锁。其次，进程运行推进顺序与速度不同，也可能产生死锁。

四个必要条件：
（1） 互斥条件：一个资源每次只能被一个进程使用。
（2） 占有且等待：一个进程因请求资源而阻塞时，对已获得的资源保持不放。
（3）不可强行占有:进程已获得的资源，在末使用完之前，不能强行剥夺。
（4） 循环等待条件:若干进程之间形成一种头尾相接的循环等待资源关系。

怎么避免死锁？

死锁避免：

(1)两种死锁避免算法：

*进程启动拒绝：如果一个进程的请求会导致死锁，则不启动该进程。

*资源分配拒绝：如果一个进程增加的资源请求会导致死锁，则不允许此分配(银行家算法)

对象锁和类锁是否会互相影响？

多线程有什么要注意的问题？

如何保证多线程读写文件的安全？

mmap

多线程断点续传原理

断点续传的实现

AQS

所谓AQS，指的是AbstractQueuedSynchronizer，它提供了一种实现阻塞锁和一系列依赖FIFO等待队列的同步器的框架，ReentrantLock、Semaphore、CountDownLatch、CyclicBarrier等并发类均是基于AQS来实现的，具体用法是通过继承AQS实现其模板方法，然后将子类作为同步组件的内部类。

AQS详解
AQS的核心思想是，
如果被请求的共享资源空闲，则将当前请求资源的线程设置为有效的工作线程，并将共享资源设置为锁定状态，
如果被请求的共享资源被占用，那么就需要一套线程阻塞等待以及被唤醒时锁分配的机制，这个机制AQS是用CLH队列锁实现的，即将暂时获取不到锁的线程加入到队列中
https://blog.csdn.net/mulinsen77/article/details/84583716