AOP的两种通用配置

AspectJ的xml：
1.配置事务管理器
2.配置事务的通知（事务的增强）<tx:advice>
3.配置切面（切入点pointcut ;切面advisor-ref:advice）
基于注解：
1.配置事务管理器
2.开启注解事务<tx:anotation-driven >
3.类上添加注解@Transanctional

redis的持久化RDB和AOF

RDB是在指定时间间隔内将数据集快照写入磁盘，利于备份，可以随时将数据集还原到不同的版本；适用于灾难恢复，可将数据发送到别的数据中心；可以最大化 Redis 的性能：父进程在保存 RDB 文件时唯一要做的就是 fork 出一个子进程，然后这个子进程就会处理接下来的所有保存工作，父进程无须执行任何磁盘 I/O 操作；在恢复大数据集时的速度比 AOF 的恢复速度要快。
高可用问题是他的一个缺点，一旦宕机会丢失未保存的数据；在数据集比较庞大时， fork()可能会非常耗时。
AOF更好的保证了数据的一致性，日志写入采用append模式，宕机不会丢失已有的内容，redis-check-aof 工具也可以轻易地修复未写入完整的命令（比如写入时磁盘已满，写入中途停机）

Redis做异步队列

一个是使用生产者消费模式模式:会让一个或者多个客户端监听消息队列，一旦消息到达，消费者马上消费，谁先抢到算谁的，如果队列里没有消息，则消费者继续监听
另一个就是发布订阅者模式:也是一个或多个客户端订阅消息频道，只要发布者发布消息，所有订阅者都能收到消息，订阅者都是平等的。
一般使用list结构作为队列，rpush生产消息，lpop消费消息。当lpop没有消息的时候，要适当sleep一会再重试。
如果不用sleep呢？list还有个指令叫blpop，在没有消息的时候，它会阻塞住直到消息到来。
能不能生产一次消费多次呢？
使用pub/sub主题订阅者模式，可以实现1:N的消息队列。pub/sub有什么缺点？在消费者下线的情况下，生产的消息会丢失，得使用专业的消息队列如rabbitmq等。

tcp为什么要三次握手，而不能二次握手

谢希仁版《计算机网络》中的例子是这样的，“已失效的连接请求报文段”的产生在这样一种情况下：client发出的第一个连接请求报文段并没有丢失，而是在某个网络结点长时间的滞留了，以致延误到连接释放以后的某个时间才到达server。本来这是一个早已失效的报文段。但server收到此失效的连接请求报文段后，就误认为是client再次发出的一个新的连接请求。于是就向client发出确认报文段，同意建立连接。假设不采用“三次握手”，那么只要server发出确认，新的连接就建立了。由于现在client并没有发出建立连接的请求，因此不会理睬server的确认，也不会向server发送ack包。（校注：此时因为client没有发起建立连接请求，所以client处于CLOSED状态，接受到任何包都会丢弃，谢希仁举的例子就是这种场景。但是如果服务器发送对这个延误的旧连接报文的确认的同时，客户端调用connect函数发起了连接，就会使客户端进入SYN_SEND状态，当服务器那个对延误旧连接报文的确认传到客户端时，因为客户端已经处于SYN_SEND状态，所以就会使客户端进入ESTABLISHED状态，此时服务器端反而丢弃了这个重复的通过connect函数发送的SYN包，见第三个图。而连接建立之后，发送包由于SEQ是以被丢弃的SYN包的序号为准，而服务器接收序号是以那个延误旧连接SYN报文序号为准，导致服务器丢弃后续发送的数据包）但server却以为新的运输连接已经建立，并一直等待client发来数据。这样，server的很多资源就白白浪费掉了。采用“三次握手”的办法可以防止上述现象发生。例如刚才那种情况，client不会向server的确认发出确认。server由于收不到确认，就知道client并没有要求建立连接。
在谢希仁著《计算机网络》第四版中讲“三次握手”的目的是“为了防止已失效的连接请求报文段突然又传送到了服务端，因而产生错误”。在另一部经典的《计算机网络》（Andrew S.Tanenbaum著，第四版）一书中讲“三次握手”的目的是为了解决“网络中存在延迟的重复分组”的问题。这两种不同的表述其实阐明的是同一个问题。

设计线程池

https://blog.csdn.net/zp17764507932/article/details/54582881
1）线程池管理类
主要用于实现创建线程和添加客户端请求的新任务，执行任务以及如何回收已经执行完任务的线程。
2）工作线程类
线程池中的线程，它主要用于处理任务队列中的任务。
3）任务类
定义任务的各种属性，以及要完成的操作
4）任务队列
按先来先服务的顺序用于存放新加入的任务，以便让工作线程来执行

1.初始化线程池，指定线程池的大小。
2.向线程池中放入任务执行。
3.如果线程池中创建的线程数目未到指定大小，则创建我们自定义的线程类放入线程池集合，并执行任务。执行完了后该线程会一直监听队列
4.如果线程池中创建的线程数目已满，则将任务放入缓冲任务队列
5.线程池中所有创建的线程，都会一直从缓存任务队列中取任务，取到任务马上执行

CAS

CAS有3个操作数，内存值V，旧的预期值A，要修改的新值B。当且仅当预期值A和内存值V相同时，将内存值V修改为B，否则什么都不做。CAS是乐观锁的一种实现方式。

Mybatis二级缓存

1.MyBatis配置文件（SqlMapConfig.xml）打开二级缓存cacheEnabled
2.Mapper配置文件添加cache标签
<cache type="org.mybatis.caches.ehcache.EhcacheCache"/>
3.缓存实体类继承序列化接口
public class User implements Serializable
用eviction配置缓存策略FIFO,LRU

现实生活中的封装继承多态的理解

封装：
首先，属性可用来描述同一类事物的特征，行为可描述一类事物可做的操作，封装就是要把属于同一类事物的共性(包括属性与行为)归到一个类中，以方便使用。比如人这个东西，可用下面的方式封装：
人{　年龄(属性一)
身高(属性二)
　　性别(属性三)

吃饭(行为之一)
　　走路(行为之二)
　　说话(行为之三)
}
继承：
由于封装，使得有共同特征的一类事物的所有描述信息都被归于一类之中，但我们知道，这并不是万能的，有些事物有共性，但还存在区别，比如码农的行为还有敲代码，就可以继承人，如：
码农 extends 人{
　　敲代码(行为之四)
}
这样，我们就不用重新定义那些已经被“人”这一个类所封装的那些属性与行为了，而只需要使用继承的方式，在人的基础上拓展码农专有的行为。
多态：
就是站在抽象的层面上去实施一个统一的行为，到个体(具体)的层面上时，这个统一的行为会因为个体(具体)的形态特征而实施自己的特征行为。
比如，上班时间到了，老板喊一声：“大家干活了！”于是所有人就各忙各的去了。如果老板不运用多态的方法，那就需要喊一句：“前台去接待了，业务员去销售了，人事去招聘了，清洁工去扫地了，码农去敲代码了

触发器和存储过程

触发器与存储过程的主要区别在于触发器的运行方式。存储过程必须有用户、应用程序或者触发器来显示的调用并执行，而触发器是当特定时间出现的时候，自动执行或者激活的，与连接用数据库中的用户、或者应用程序无关。当一行被插入、更新或者删除时触发器才执行，同时还取决于触发器是怎样创建的，当UPDATE发生时使用一个更新触发器，当INSERT发生时使用一个插入触发器，当DELETE发生时使用一个删除触发器。

自旋锁

轻量级锁失败后，虚拟机为了避免线程真实地在操作系统层面挂起，还会进行一项称为自旋锁的优化手段。这是基于在大多数情况下，线程持有锁的时间都不会太长，如果直接挂起操作系统层面的线程可能会得不偿失，毕竟操作系统实现线程之间的切换时需要从用户态转换到核心态，这个状态之间的转换需要相对比较长的时间，时间成本相对较高，因此自旋锁会假设在不久将来，当前的线程可以获得锁，因此虚拟机会让当前想要获取锁的线程做几个空循环(这也是称为自旋的原因)，一般不会太久，可能是50个循环或100循环，在经过若干次循环后，如果得到锁，就顺利进入临界区。如果还不能获得锁，那就会将线程在操作系统层面挂起，这就是自旋锁的优化方式，这种方式确实也是可以提升效率的。最后没办法也就只能升级为重量级锁了。

synchronized实现原理

monitorenter:
每个对象都有一个监视器锁(monitor)，当monitor被占用时就会处于锁定状态。线程执行monitorenter命令获取monitor锁的过程如下：
1、如果monitor的进入数为0，则线程获取锁，并设置monitor的进入数为1
2、如果该线程已经占有该monitor，则进入数+1
3、如果其他线程占有该monitor，则monitor的进入数不为0，则该线程进入阻塞状态，直到monitor为0，重新获取monitor的所有权
monitorexit:
执行monitorexit的线程必须是monitor的所有者。
当执行该命令时，monitor的进入数-1，当monitor的进入数为0，该线程已经不再是该monitor的所有者，其他被这个monitor阻塞的线程可以尝试获取monitor的所有权。

mybatis的接口到数据库的映射过程

https://blog.csdn.net/u011420057/article/details/72454710
userDAO属性被注解为@Autowired，由spring完成bean的自动装配，其中spring会去获取一个MyBatis的mapperProxy代理对象作为这个bean，它是一个真正的对象而不是一个Interface类型，由这个代理人完成到数据库的映射。 通过调用特定的mapper代理对象的invoke()方法，实现到数据库的映射，实际上invoke()中又调用了MapperMethod中的execute方法，execute方法主要是用到sqlSession的insert、update、select、delete等

讲一讲AQS

AQS主要基于整型的volatile变量来维持同步状态，通过内置 的FIFO队列来完成资源获取线程的排队工作。AQS的独占锁：同一时刻只允许一个线程占用锁，不支持可重入。共享锁：同一时刻允许多个线程占用锁。

类加载器

主要有委托，可见性，单一性三个机制，遵循双亲委派原则。假设要加载A.class文件，首先加载这个类的请求由Application类加载器委托到他的父加载器Extension类加载器，然后再委托到Bootstrap类加载器，Bootstrap会先看看rt.jar中有没有这个类，没有的话回到Extension类加载器，他会查看jre/lib/ext目录下有没有该类，没有的话，再由Application类加载器从classpath中寻找。

线程共享和线程私有的部分

共享：进程代码段，进程共有数据，进程打开的文件描述符，信号的处理器。
私有: 线程ID，寄存器的值，线程的堆栈，错误的返回码，线程优先级。
何时用多进程，何时用多线程？
对资源管理和保护要求高，不限制开销和效率用多进程。反之，要求效率高，频繁切换，资源的保护管理要求不是很高时，使用多线程。

ZAB协议

ZAB协议要求每个leader都要经历三个阶段，即发现，同步，广播。
发现：即要求zookeeper集群必须选择出一个leader进程，同时leader会维护一个follower可用列表。将来客户端可以这follower中的节点进行通信。
同步：leader要负责将本身的数据与follower完成同步，做到多副本存储。这样也是体现了CAP中高可用和分区容错。follower将队列中未处理完的请求消费完成后，写入本地事物日志中。
广播：leader可以接受客户端新的proposal请求，将新的proposal请求广播给所有的follower。
ZAB协议中主要有两种模式，第一是消息广播模式；第二是崩溃恢复模式
崩溃恢复：选举拥有 proposal 最大值（即 zxid 最大） 的节点作为新的 leader：由于所有提案被 COMMIT 之前必须有合法数量的 follower ACK，即必须有合法数量的服务器的事务日志上有该提案的 proposal，因此，zxid最大也就是数据最新的节点保存了所有被 COMMIT 消息的 proposal 状态。

GC调优

1.避免新生代大小设置过小
当新生代设置过小时，会产生两种比较明显的现象，一是minor GC次数频繁，二是可能导致 minor GC对象直接进入老年代。当老年代内存不足时，会触发Full GC。
2.避免新生代设置过大
新生代设置过大，会带来两个问题：一是老年大变小，可能导致Full GC频繁执行；二是 minor GC 执行回收的时间大幅度增加。
3.避免Survivor区过大或过小
-XX:SurvivorRatio参数的值越大，就意味着Eden区域变大，minor GC次数会降低，但两块Survivor区域变小，如果超过Survivor区域内存大小的对象在minor GC后仍没被回收，则会直接进入老年代，
-XX:SurvivorRatio参数值设置过小，就意味着Eden区域变小，minor GC触发次数会增加，Survivor区域变大，意味着可以存储更多在minor GC后任存活的对象，避免其进入老年代。
4.合理设置对象在新生代存活的周期
新生代存活周期的值决定了新生代对象在经过多少次Minor GC后进入老年代。因此这个值要根据自己的应用来调优，Jvm参数上这个值对应的为-XX:MaxTenuringThreshold，默认值为15次。