面试八股加油背

双重检查机制，锁住部分方法体

synchronized关键字来异步锁住方法

创建一个内部类Holder，在内部类中定义实例，由于内部类只有在被调用时才被加载，<br>用JVM实现了懒汉式，并且没有线程安全的问题

要求传入的对象实现了接口

创建一个ProxyFactory来根据目标对象去生成一个代理对象<br>，ProxyFactory通过java.lang.reflect.Proxy类的newProxyInstance方法<br>传入目标对象的类加载器，对象实现的接口，以及一个InvocationHandler的匿名内部类<br>实现他的invoke方法，来调用他的方法并且在中间增加事务<br>

基于子类来实现，传入的目标对象类不能是final修饰

当目标对象没有实现接口时使用CGlib动态代理

尽量少的去修改父类的方法，而是在继承时去扩展方法

TCP连接的每一方都有固定大小的缓冲空间，TCP的接收端只允许发送端发送接收端缓冲区能接收的数据<br>，如果接受端来不及接收数据，就提示发送方降低发送的速率，防止包丢失

当网络拥塞时减少数据的发送

使用大小数组+链表的形式，每次锁只锁住整个小数组，不对大数组加锁，大数组初始<br>容量大小为16，大数组不会扩容，只有小数组会扩容，小数组使用扩容因子进行扩容，每次<br>扩容两倍，因为大数组不会扩容，所以他的并发度是固定的，整体比较臃肿<br>

采用和hashmap一样的数据结构，数组+链表/红黑树，在hashmap中加入了线程<br>安全的操作，使用node+cas+synchronized方式来保证安全

初始化数组时使用cas锁

添加元素时，如果数组对应位置没有元素，就用cas自旋锁添加，如果有元素，就<br>对一个数组下标加锁，来实现线程安全

必须方法只有一个参数

必须是实现类只有一行

获取流操作

中间操作

最终操作

核心线程数

最大线程数

等待时间

等待时间的单位

阻塞队列

线程工厂

拒绝的策略

Executors类创建

通过ThreadPoolExecutor创建

为什么要使用ThreadPoolExecutor创建而不是Executors？<br>Executors创建的线程池，其中FixedThreadPool和SingleThreadExecut请求队列的<br>长度是Integer.MAX_VALUES,而CachedThread 和 ScheduledThread允许创建线程<br>的数量是Integer.MAX_VALUE,<br>请求队列过长会堆积大量的请求，而允许创建线程数过大会创建大量的线程，这都会导致<br>内存溢出 OOM，所以要通过ThreadPoolExecutor创建，来指定参数创建线程池<br>

对于CPU密集型的任务，设置成CPU的数量 + 1

对于IO密集型的任务，设置成CPU数量 * 2

乐观锁的实现方式

在这个类中又有ReadLock和WriteLock,来实现读锁<br>和写锁

读锁与读锁兼容与写锁互斥

实现Lock接口

写锁与读锁和写锁都互斥

为什么要用while循环判断，而不是用<br>if判断？防止虚假唤醒<br>

对于某些场景下,ABA问题是不需要解决的，比如在买票卖票<br>的场景下，cas自旋锁自旋等待修改为预期值是，数值已经由A到<br>B再由B到A了，此时执行了修改语句，这种情况下相当于有人退票<br>另一个人把别人退的票抢到了，这种情况下是没有问题的

而对于有些应用场景，ABA问题是不被允许的，就比如对于开保险箱的场景下，一个保险箱如果<br>已经被开启过又关闭又开启，那这种情况是不被允许的，就需要处理ABA问题

最常用的方式就是使用版本号机制+CAS自旋锁，当版本号与修改前不一致<br>就废弃这次操作，重新执行

set方法，ThreadLocal以自己做key，用set的对象做value

get，以自己做key，获取对应的value

remove，以自己做key，删除当前线程对应的相关信息

首先存在一个代理对象和目标对象，目标对象执行具体的方法，他们同时实现同一个接口，创建代理对象<br>代理对象中有目标对象的属性，代理对象实现方法时会先实现目标对象的方法，然后在实现方法前后去加入增强代码<br>比如权限控制，日志处理

为什么要用动态代理而不用静态代理，对于静态代理需要创建大量的代理类，并且如果要维护代理的方法就需要该的代码很多，因此有了动态代理

JDK动态代理

CGlib动态代理

@Before前置通知

@AfterReturning后置通知

@Round环绕通知

切面表达式，表示对于哪些返回值的那些类的哪些方法进行aop

最终通知

异常通知

表示需要切入的位置，某些类或者某些方法<br>

构造器注入

setter方法注入

@Autowired

@Resource

默认情况下只开启一级缓存，对于一级缓存只针对一个SqlSession而言，对于相同参数的相同SQL语句<br>MyBatis会存储他的结果，只针对同一个SqlSession，当一次会话结束后就会销毁

针对namespace会创建一个缓存区，被多个SqlSession共享，当一个sqlsession结束后会将一级缓存的内容<br>存储到二级缓存中

默认不开启

if

where

foreach

choose

when

otherwise

set

在controller执行之前拦截

在执行完controller方法之后执行<br>

在渲染完视图以后执行

首先他会从单例池中getBean去获取bean对象

如果bean对象中没有对应的bean对象就回去实例化bean

再对bean进行属性填充

再对bean进行初始化

检查是否已经创建了aop的代理对象，如果没有就调用后置处理去创建aop的代理方法放在单例池中<br>有的话就将半成品池中的代理对象放到单例池中，再创建

热门数据永不过期

加互斥锁<br>

针对redis热点内存失效的情况

针对redis服务不可用的情况

单独的隔离操作

不保证原子性

没有隔离级别的概念

采用版本号机制来解决问题实现事务

使用wathc key命令来监视一个数据，如果在执行前该数据有改动，就会将当前事务打断

redis中两个字段分别是库存和购买的用户id的集合，当购买以后将库存-1，将用户id加入到set集合中去，并且<br>在每次购买前检查用户是否已经购买过

对于不采用任何措施的场景下，如果大量线程并发涌入，会导致多卖的情况产生，在别的线程修改库存之前，<br>其他线程已经通过if判断，导致商品多买<br>

悲观锁解决：使用synchronized关键字可以解决这个问题，加锁让所有线程串行执行，问题就是速度会大大降低

使用redis事务+乐观锁解决超卖问题，会产生问题：

使用lua脚本解决库存遗留问题

save方法实现RDB，这种方法是不被推荐的，他是使用redis的主进程去备份redis中的数据，那么都知道redis的单线程的<br>如果主进程去进行RDB操作，就会影响到用户的后续操作

bgsave方法，启动后台线程去执行rdb操作，不影响主进程

always,每次aof命令都直接写入到aof文件中去

everysec每执行一次命令，就将命令写入到aof缓冲区，在每秒将缓冲区的数据写入到aof文件中去

no,命令执行完写入缓存区，什么时候写入到aof由操作系统决定，这种可靠性是最差的

优化aof日志中的命令，比如对于同一个key的多次写只记录最后一次，用最少的命令达到相同的效果

master执行bgsave命令，生成后台进程生成RDB文件，发送RDB文件，<br>slave清空本地数据，加载RDB文件，再将RDB期间的所有命令写到缓冲区<br>中去，然后将缓冲区中的内容发送到slave中

比较消耗性能的，比较慢，因为RDB文件他是需要将所有的数据拷贝到RDB文件中去，所以只有第一次会进行全量同步

master如何判断slave是第一次同步数据

如果slave重启后同步，则执行增量同步

减少全量同步的次数

提高全量同步的效率

采用主从从链式结构的redis节点，减少master的压力

用来实现主从集群的故障恢复

监控：不断的检查您的master和slave是否正常工作

自动故障恢复：如果master故障，sentinel会将一个slave提升为master，当故障实例恢复后也以<br>新的master为主

通知redis客户端的服务发现的来源，当故障转移时将最新信息<br>推送给客户端

每隔1秒向集群的每个实例发送ping命令

主观下线：如果某个实例规定时间内未响应，则认为该实例主观下线

客观下线：若超过一定数量的sentinel认为该实例下线，则认为该实例客观下线

排除于master断开时间超过指定值的slave节点

判断slave节点和slave-priority值，在配置文件里配置的，优先级值，默认大家一样

判断offset值，值越大越新，优先级越高

最后判断slave节点的运行id大小，越小优先级越高

sentinel向新的master执行slaveof no one,让他成为master

向其他的节点更新master节点的ip和端口号 slaveof 新masterip 端口号

对于旧的master也发送将新的master认为是主节点的命令

作用：加载Class文件

包括虚拟机自带的加载器

启动类加载器&nbsp;

扩展类加载器

应用程序加载器

作用：保证安全

当jvm加载一个类时，他会先去根据根加载器去加载这个类，如果根加载器<br>中没有这个类，再去扩展加载器，再去应用程序加载器

为什么要这么做？为了保护java定义的类，比如我们自己定义了一个<br>java.lang.String的类，然后去执行，那么java不会去优先去找我们自己定义<br>的，而是先去跟加载器里找，也就是找java自己定义的类，这样就保证了代码的<br>安全性，防止有人去写一个String类去破坏java代码

java无法查看根加载器，因为它是一个本地方法用native修饰，也就是<br>c语言写的方法，所以java无法读取到

确保Classs文件的字节流中包含的信息是否符合当前虚拟机的需求保证被加载类的正确性，不会危害虚拟机自身的安全

创建类的static变量创建内存地址并且设置成默认值<br>

将常量池内的符号引用转换为直接引用的过程

什么是符号引用，什么是直接引用

堆是所有线程共享的，需要考虑线程安全的问题

有垃圾回收机制

设置堆空间最大值的虚拟机参数 -Xmx

堆内存溢出 OOM

堆内存诊断

堆的区域

栈是线程运行需要的内存空间

栈帧

垃圾回收不回收栈内存

栈内存不是越大越大，过大会导致进程能创建的线程数减少，能增加递归调用的层数

通过虚拟机参数-Xss设置栈内存大小

栈内存溢出

线程诊断

用来记录JVM要运行的下一条执行

程序计数器是线程私有的，属于当前线程

不会存在内存溢出

对于每个对象添加一个计数器，如果他增加一个引用就+1，减少一个引用就-1，如果一个对象的引用是0<br>，那就清除这个对象

缺点

优点

可达性算法会从GCroot出发，形成一个引用链，将引用链的所有对象标记为可达，不需要清理，<br>对于不可达的对象进行清理

优点

哪些对象是GCroot对象？

注意事项

清除标记阶段没有标记的内存对象<br>

会产生内存碎片，需要去维护空闲列表

需要STW，用户体验比较查

第一阶段和标记清除阶段一样，从根节点开始标记所有被引用对象

第二阶段将所有存活的对象压缩到内存的一段按顺序排放，之后清理边界以外的所欲空间

优点

缺点

没有标记的过程，将可达的对象，直接复制到内存大小相同的另一个区域中区，并且连续存放，<br>复制完成后，A区全部清理，下一次再从B区复制到A区，A区全部清理

优点

缺点

引用场景

如果活动对象太多，每层都需要复制很多，效率很低<br>对于老年代的GC，存在很多的活动对象，效率就比较低

对于不同的对象的声明周期是不同的，因此对于不同的声明周期的对象采用不同的收集方式，来提高回收效率

java将堆分为新生代和老年代，根据不同代的特点使用不同的回收算法，提高效率

新生代

老年代

最常用的索引结构

B树和B+树的区别

不支持范围查询，只支持单个查询

MyIsam引擎特有的索引，用于地理空间数据类型

用于快速匹配文档

二叉树

红黑树

B树

多个字段组成的索引

单个字段的索引

根据主键生成的索引

唯一索引的字段不能重复

根据索引的字段建立B+树，叶子节点存放主键ID，再根据sql语句<br>查询的字段看有没有覆盖索引，要不要进行回表查询（再根据主键对聚集索引进行查询

根据主键建立的B+树，数据存放在叶子节点

分表

读写分离

redis缓存

表空间

段

区

页

行

一个区是1M,一个页是16K，一个区有64个连续的页

内存结构

磁盘结构

读锁（读共享锁

写锁（写独占锁或者叫排他锁

用于避免当添加表锁时，需要一次检查每一行的行锁是否与表锁互斥，因此<br>增加意向锁，当添加行锁时，会向表添加意向锁，这样后面其他表锁要添加时<br>只需要判断与意向锁是否互斥就可以了，不需要扫描所有行锁

意向共享锁

意向排他锁

DQL和DML都会自动加上共享读锁和共享写锁，相互之间不是互斥的

对于alter 语句该表表结构，那么会和共享读锁和共享写锁互斥

为了解决执行DML语句和DDL语句之间的冲突问题的，所以这个锁它无论是读锁和写锁<br>他都是兼容的，但是对于alter语句也就是DDL语句，他是互斥的

共享锁 和共享锁兼容 和排他锁冲突

排他锁 和共享锁和排他锁都冲突

保证索引记录间隙，确保索引记录间隙不变，防止其他事务在这个间隙insert，产生幻读<br>在RR隔离级别下支持

行锁和临键锁 ，在RR隔离级别下支持

指对于事务，要么全部成功，要么全部失败，通过undo log日志实现事务的回滚操作<br>当事务中的语句发生错误时，通过undo log 日志回滚之前的操作实现原子性

通过其他的三个属性来保证，意思是事务的执行结束后，如果事务回滚，那么数据库<br>中的数据和事务执行前保持一致，如果事务提交，那么提交后的数据库的数据是完整的<br>

隔离性的三个级别

spring相关事务隔离性<br>使用@Transactional注解添加事务

隔离性是底层是通过MVCC+锁来实现的，快照读也就是不同的select语句是通过MVCC来实现的，而当前读也就是DML语句和select...for update 和<br>select ...lock in share mode 是通过加锁来实现的，对于不同的语句加的锁的粒度也是不同的，

持久性是底层是通过redo log 日志来实现的，对于已经提交的事务，redo log会记录数据的物理信息，并且提交到磁盘上，当磁盘刷新脏页<br>时出现错误，就可以通过redo log 日志来实现数据的恢复，保证数据的持久性

读脏数据

不可重复读

幻读

读取的是最新版本，会加对应的行锁 比如select ....lock in share mode 会加共享锁<br>select ... for update,insert,update,delete 会加独占锁<br>他们的读都是当前读&nbsp;

一种非阻塞读，它读取的不一定是数据的最新版本

不同事务或相同事务对同一行数据的修改会产生一条undo log版本链

读视图，它是快照读sql读取版本的依据，包含四个字段<br>当前活跃的事务id集合<br>活跃的最小事务id<br>预备事务的ID集合（活跃的最大事务的ID+1<br>ReadView创建者的事务ID

通过版本链数据访问规则来确定快照读到底访问undo Log版本链中的哪段数据

版本链数据访问规则<br>1.&nbsp;&nbsp;trx_id&nbsp;==&nbsp;creator_trx_id&nbsp;&nbsp;可以访问该版本<br>2.&nbsp;trx_id&nbsp;==&nbsp;min_trx_id&nbsp;&nbsp;&nbsp;可以访问，说明事务已经提交了<br>3.&nbsp;trx_id&nbsp;&gt;&nbsp;max_trx_id&nbsp;&nbsp;不可以访问该版本&nbsp;&nbsp;&nbsp;不可以访问&nbsp;说明该事务是在ReadView&nbsp;生成后才开启的<br>4.&nbsp;min_trx_id&nbsp;&lt;=&nbsp;trx_id&nbsp;&lt;=&nbsp;max_trx_id&nbsp;&nbsp;如果trx_id&nbsp;不在m_ids&nbsp;中是可以访问该版本的&nbsp;&nbsp;说明数据已经提交

在RC隔离级别下，每次快照读都会生成新的ReadView，实现每次读取<br>undo log版本链中已经提交事务的版本

在RR隔离级别下，只有第一次快照读会生成ReadView，后面的快照读沿用第一次的<br>ReadView，因此后面每一次读取的结果都是一致的，这也就是为什么叫可重复读，事务<br>每次重复读的ReadView都相同，那么读取的undo log版本链中的数据也相同

其他区别

左外连接left join

右外连接 right join

全外连接 full join