面试准备

线程池知识

参考：【https://www.jianshu.com/p/87bff5cc8d8c】

image.png

线程池提交

通过Executor.execute()方法提交的任务，必须实现Runnable接口，该方式提交的任务不能获取返回值，因此无法判断任务是否执行成功。

通过ExecutorService.submit()方法提交的任务，可以获取任务执行完的返回值，必须继承Runnable 接口

#######虚假唤醒 （平时用不到） spurious wakeup
一个线程能在没有被通知、中断或超时的情况下唤醒，也即所谓的“虚假唤醒”

待解决：为什么 wait 方法必须放在 while 循环体内执行？

题外话：Netty的一个坑
因为 Netty 里面，其核心的 Future 接口实现中，犯了一个基本的逻辑错误，在实现 cancel 和 isDone 方法是违反了 JDK 的约定。
java中规定如果调用了 cancel 方法，那么再调用 isDone 将永远返回 true。
在netty中 在调用了 cancel 方法后，再次调用 isDone 方法，返回的确是 false。

image.png

image.png

futuretask中使用的是cas锁 UNSAFE里面都是native c实现

Synchronized

https://blog.csdn.net/tongdanping/article/details/79647337
1.使用synchronized修饰非静态方法或者使用synchronized修饰代码块时制定的为实例对象时，同一个类的不同对象拥有自己的锁，因此不会相互阻塞。
2.使用synchronized修饰类和对象时，由于类对象和实例对象分别拥有自己的监视器锁，因此不会相互阻塞。
3.使用使用synchronized修饰实例对象时，如果一个线程正在访问实例对象的一个synchronized方法时，其它线程不仅不能访问该synchronized方法，该对象的其它synchronized方法也不能访问，因为一个对象只有一个监视器锁对象，但是其它线程可以访问该对象的非synchronized方法。
4.线程A访问实例对象的非static synchronized方法时，线程B也可以同时访问实例对象的static synchronized方法，因为前者获取的是实例对象的监视器锁，而后者获取的是类对象的监视器锁，两者不存在互斥关系。

monitorenter
monitorexit
指令
mark word被分成两部分，lock word和标志位。
汇编？还是java字节码
偏向锁：方法的对象头中加入线程id。如果下次访问不变则不需要进行CAS操作进行加锁和解锁（因为CAS原子指令虽然相对于重量级锁来说开销比较小但还是存在非常可观的本地延迟）。
轻量级锁：CAS
重量级锁：当锁处于这个状态下，其他线程试图获取锁都会被阻塞住，当持有锁的线程释放锁之后会唤醒这些线程。
升级机制
偏向锁==》轻量级锁 另一个线程要求该对象时发现发现方法头里面的线程没有挂掉
轻量级锁==》重量级锁 轻量级锁cas自旋好多次后发现还是在自旋或者有另一个对象来竞争 （自旋也是消耗cpu的）
会升级但不会降级 除了偏向锁可以被设置为无锁模式

image.png

自旋锁：为了防止频繁的挂起和恢复线程导致的时间消耗

volatile

https://www.jianshu.com/p/d3fda02d4cae
volatile是基于Memory Barrier实现的。
这意味着，如果写入一个volatile变量a，可以保证：
1、一个线程写入变量a后，任何线程访问该变量都会拿到最新值。
2、在写入变量a之前的写入操作，其更新的数据对于其他线程也是可见的。因为Memory Barrier会刷出cache中的所有先前的写入。

LockSupport

出现之前都是用的wait notify
但是wait和notify/notifyAll方法只能在同步代码块里用
多次执行后，我们会发现：有的时候能够正常打印结果并退出程序，但有的时候线程无法打印结果阻塞住了。原因就在于主线程调用完notify后，线程A才进入wait方法，导致线程A一直阻塞住。由于线程A不是后台线程，所以整个程序无法退出。

那如果换做LockSupport呢？LockSupport就支持主线程先调用unpark后，线程A再调用park而不被阻塞吗？是的，没错。
小结一下，LockSupport比Object的wait/notify有两大优势：
LockSupport不需要在同步代码块里 。所以线程间也不需要维护一个共享的同步对象了，实现了线程间的解耦。
unpark函数可以先于park调用，所以不需要担心线程间的执行的先后顺序。
多次调用unpark方法与一次调用结果是一样的，都是讲_counter赋值为一。
https://blog.csdn.net/zyzzxycj/article/details/90268381

AtomicInteger

i++线程不安全 因为不是原子性操作
原子类相比于普通的锁，粒度更细、效率更高(除了高度竞争的情况下)
如何把普通变量升级为原子变量？主要是AtomicIntegerFieldUpdater类

AtomicInteger是lock free AtomicInteger 主要是依赖于 sun.misc.Unsafe 提供的一些 native 方法保证操作的原子性。

ABA问题：AtomicStampedReference
JDK 1.5 以后的 AtomicStampedReference 类就提供了此种能力，其中的 compareAndSet 方法就是首先检查当前值是否等于预期值，判断的标准就是当前引用和邮戳分别和预期引用和邮戳相等，如果全部相等，则以原子方式设置为给定的更新值。
其实就是多版本控制

AQS

不仅支持独占模式 同时支持共享模式下的同步实现
函数分为三类：
1.类似acquire(int)的一类是最基本的一类，不可中断
2.类似acquireInterruptibly(int)的一类可以被中断
3.类似tryAcquireNanos(int, long)的一类不仅可以被中断，而且可以设置阻塞时间
独占模式下只有当tryAcquire返回true的时候我们才能确定获得资源了，而在共享模式下，只要tryAcquireShared返回值大于等于0就可以说明获得资源了，。

ReentrantLock

基于AQS实现 独占锁 可重入锁
重入性表现在同一个线程可以多次获得锁
公平锁和非公平锁 =队列和抢占
公平锁：每个线程获取锁的过程是公平的，等待时间最长的会最先被唤醒获取锁。
非公平锁：同等优先级的竞争 无所谓谁先等待 失败的继续等待
条件变量Condition ：很大一个程度上是为了解决Object.wait/notify/notifyAll难以使用的问题。
Synchronized中，所有的线程都在同一个object的条件队列上等待。而ReentrantLock中，每个condition都维护了一个条件队列。
每一个Lock可以有任意数据的Condition对象，Condition是与Lock绑定的，所以就有Lock的公平性特性：如果是公平锁，线程为按照FIFO的顺序从Condition.await中释放，如果是非公平锁，那么后续的锁竞争就不保证FIFO顺序了。
Condition接口定义的方法，await对应于Object.wait，signal对应于Object.notify，signalAll对应于Object.notifyAll。特别说明的是Condition的接口改变名称就是为了避免与Object中的wait/notify/notifyAll的语义和使用上混淆。

Java同步器

https://blog.csdn.net/DengDeng_G/article/details/79041134
包括了信号量(Semaphore)、计数栓(CountDownLatch)、循环屏障(CyclicBarrier)、交换器(Exchanger)、Phaser
AQS框架也是同步器
https://blog.csdn.net/DengDeng_G/article/details/79041134

Phaser同步器没看懂

CountDownLatch面试题

8.10 腾讯面试问题

1.redis+mysql超卖问题如何解决

2.hbase底层架构和组成

4.线程池核心参数

忘了说不同线程池参数的不同
long keepAliveTime,TimeUnit unit,这个两个也忘了说

4.线程池阻塞队列满了之后的三种情况

image.png

5.hashmap和concurrenthashmap区别

6.如何了解新的技术

7.AQS

image.png

https://www.jianshu.com/p/853b203a8d93
https://blog.csdn.net/python8989/article/details/113666420
面试官问我了AQS 我说这个底层其实就是CAS 函数有tryaquire（） tryaquireShared（） 但其实不对 应该更细节的把AQS底层逻辑都讲一下 包括自旋锁 还有node队列，对于队列的操作 非公平锁和公平锁 还有locksupport
需要看一下公平锁非公平锁释放和获取 lock和release的源码
注意：AQS里有node syn继承AQS也有 ReentrantLock使用的AQS中的

https://www.jianshu.com/p/4358b1466ec9
AQS中node【https://blog.csdn.net/qq_43986945/article/details/101345713】