1. 大量反射代码使永久代类太多导致频繁Full GC
解决方案：在有大量反射代码的场景下，只要把-XX:SoftRefLRUPolicyMSPerMB=0，这个参数设置大一些即可，千万别让一些新手同学设置为0，可以设置个1000，2000，3000，或者5000毫秒，都可以。提高这个数值，就是让反射过程中JVM自动创建的软引用的一些类的Class对象不要被随便回收，优化这个参数之后，就可以看到系统稳定运行了。
2. 大对象导致频繁Full GC
解决方案，一是对SQL语句的处理，不要一次性查表里全部数据，二是给新生代分配更多的空间，毕竟每次到老年代的对象较少而且频率很低，同时给老年代调整了参“XX:CMSInitiatingOccupancyFraction=92”，避免老年代仅仅占用68%就触发GC。
3. 致命代码：**System.gc()**导致频繁Full GC
解决方案：一是平时写代码不要用System.gc()去随便触发GC，二是在JVM参数中加入-XX:+DisableExplicitGC，这个参数的意思就是禁止显式执行GC，不允许你来通过代码触发GC。
4. 内存泄漏引起CPU高负载导致频繁Full GC
Cache Aside Pattern旁路缓存模式
1.命中：程序先从缓存中读取数据，如果命中，则直接返回
2.失效：程序先从缓存中读取数据，如果没有命中，则从数据库中读取，成功之后将数据放到缓存中
3.更新:程序先更新数据库，再删除缓存
针对单点数据库，先更新数据库，再删除缓存+延时双删（删除缓存->更新数据->延时->删除缓存）基本没有太大问题。会出现的问题如下（几率很小，因为读一般比写快，写的时候数据库还要加锁之类的，所以慢）：
而实际中，大型项目会有多个数据库集群，比如读写分离情况下，主从架构模式会出现问题。
解决方案：多加了一个binlog订阅系统，去订阅主数据库的binlog数据，这样订阅到的数据一定是最新的。实现订阅mysql的binlog日志（一般用单线程，不用担心顺序错乱问题），可以用canal中间件。
还有一种方案：如果读写分离的时候，对数据一致性特别高的模块，可以读取数据的时候，一直去主库查询，因为主库一直是最新的数据。
更新缓存时失败了如何处理：
加了一个消息队列，可以是MQ或者kafka，将要更新的缓存数据放进MQ中，按顺序放好，消费消息队列时，重新更新缓存。
本地事务（数据库事务）
ACID原则
https://blog.csdn.net/u010960184/article/details/82557978
1.undo log
数据库的原子性可以利用undo日志来实现。
Undo Log的原理很简单，为了满足事务的原子性，在操作任何数据之前，首先将数据备份到Undo Log。然后进行数据的修改。如果出现了错误或者用户执行了ROLLBACK语句，系统可以利用Undo Log中的备份将数据回复到事务开始之前的状态。
数据库写入数据到磁盘之前，会把数据先缓存在内存中，事务提交时才会写入磁盘重。
如何保证持久性？
事务提交前，会把修改数据写到磁盘前，也就是说只要事务提交了，数据肯定持久化了
2.redo log
和undo log相反，redo log记录的是新数据的备份。在事务提交前，只要将redo log持久化即可，不需要将数据持久化，减少了IO的次数。
为什么往磁盘写log文件速度快？
写数据的两种方式：随机写，顺序写。
分布式事务：
跨数据源：随着业务数据规模的快速发展，数据量越来越大，单库单表逐渐成为瓶颈，所以我们对数据库进行了水平拆分，将原单库单表拆分成数据库分片，于是就产生了跨数据库事务问题。
跨服务：按照面向服务（SOA）的架构设计原则，将单业务系统拆分成多个业务系统，降低了各系统之间的耦合度，使不同的业务系统专注于自身业务，更有利于业务的发展和系统容量的伸缩。
解决分布式事务的思路：
CAP定理和BASE理论
CAP定理：一个系统无法同时满足以下三点
Consistency:一致性：写操作之后的读操作，必须返回该值（多个服务器数据保持一致）
Availability：可用性：只要收到用户的请求，服务器就必须给出回应（对和错不保证）
Partition tolerance：分区容错性：分区容错的意思就是，区间通信可能失败。比如，一台服务器放在上海，一台服务器放在北京，这就是两个区，他们之间可能因为网络问题无法通信。
要满足分区容错性的分布式系统，只能在一致性和可用性两者中，选择其中一个。
BASE理论：
解决方案：
分阶段提交
分布式事务解决手段之一，就是两阶段提交协议
二阶段提交：
二阶段提交就是根据这一思想衍生出来的，将全局事务拆分为两个阶段来执行：
阶段一：准备阶段，各个本地事务完成本地事务的准备工作。
阶段二：执行阶段，各个本地事务根据上一阶段执行结果，进行提交或回滚。这个阶段需要一个协调者，还有事务的参与者。协调者会监控各个事务的执行，都成功了才通知各个事务提交。
二阶段提交的问题：
TCC：
TCC模式可以解决2PC中资源锁定和阻塞问题，减少资源锁定时间。
基本原理：
它本质是一种补偿的思路。事务运行过程包括三个方法：
执行分为两个阶段：
粗看似乎和两阶段提交没有什么区别，但其实差别很大：
优势和缺点：
优势
TCC执行的每一个阶段都会提交本地事务并释放锁，并不需要等待其它事务的执行结果。而如果其它事务执行失败，最后不是回滚。而是进行补偿操作。这样就避免了资源的长期锁定和阻塞等待，执行效率较高，属于性能比较好的分布式事务方式。
缺点
使用场景：
可靠消息服务
这种实现方式的思路，其实是源于ebay，其基本的设计思想是将远程分布式事务拆分成一系列的本地事务。
基本原理
一般分为事务的发起者A和事务的其他参与者B：
RabbitMQ的消息确认
RabbitMQ确保消息不丢失的思路比较奇特，并没有使用传统的本地表，而是利用了消息的确认机制：
生产者确认机制：确保消息从生产者到达MQ不会有问题
消费者确认机制：确保消息能够被消费者正常消费
经过上面的两种确认机制，可以确保从消息生产者到消费者的消息安全，再结合生产者和消费者两端的本地事务，即可保证一个分布式事务的最终一致性。
消息事务的优缺点：
总结上面几种模型，消息事务的优缺点如下：
优点：
AT模式
AT模式是一种无侵入的分布式事务解决方案。可以看作是对TCC或者二阶段提交模型的一种优化，解决了TCC模式中的代码侵入，编码复杂等问题。
在AT模式下，用户只需要关注自己的业务SQL，用户的业务SQL作为一种阶段，Seata框架会自动生产事务的二阶段提交和回滚操作。
有没有感觉跟TCC的执行很想，都是分两个极端：
但AT模式底层做的事情可完全不同，而且第二阶段根本不需要我们编写，全部由Seata自己实现。也就是说：我们写的代码与本地事务时代码一样，无需手动处理分布式事务。
如何实现：
一阶段：
在一阶段，Seata会拦截“业务SQL”，首先解析SQL语义，找到业务SQL要更新的业务数据，在业务数据被更新前，将其保存成before image，然后执行业务sql，更新业务数据，在业务数据更新之后，再将其保存成after image，最后获取全局行锁，提交事务。以上操作全部在一个数据库事务内完成，这样保障了一阶段操作的原子性。
这里的before image和after image类似于数据库的undo 和 redo日志，但其实是用数据库模拟的。
二阶段提交：
二阶段如果是提交的话，因为业务sql在一阶段已经提交至数据库，所以Seata框架只需要将一阶段保存的快照数据和行锁删除掉，完成数据清理即可
二阶段回滚：
二阶段如果是回滚的话，Seata就需要回滚一阶段已经执行的业务sql。还原业务数据。回滚方式便是用before image还原业务数据；但在还原前首先要校验脏写，对比数据库当前业务数据和 after image。如果两份数据完全一致，就说明没有脏写，可以还原业务数据，如果不一致就说明有脏写，出现脏写就需要转人工处理。
详细架构和流程
Seata中的几个基本概念：
TC（Transaction Coordinator）-事务协调者
维护全局和分支事物的状态，驱动全局事务提交或回滚（TM之间的协调者）
TM（Transaction Manager）-事务管理者
定义全局事务的范围：开始全局事务，提交或回滚全局事务
RM（Resource Manager）-资源管理器
管理分支事务处理的资源，与TC交谈以注册分支事务和报告分支事务的状态，并驱动分支事务提交或回滚
TM：业务模块中全局事务的开启者
向TC开启一个全局事务
调用其他微服务
RM：业务模块执行者中，包含RM部分，负责向TC汇报事务执行状态
TM：结束对微服务的调用，通知TC，全局事务执行完毕，事务一阶段结束
TC：汇总各个分支事务执行结果，决定分布式事务是提交还是回滚
TC通知所有RM提交/回滚资源，事务二阶段结束
实操：
1.搭建一个TC服务，事务的协调者，负责各个事务的通信
（在官方网站下载TC Server）
2.在每个事务的参与者中引入RM/TM的包
3.告知每个事务的参与者，TC的地址
4.标记事务的范围（将Transactional注解改为GlobalTransactional）
5.代理数据源（拦截mybatis的数据进行处理）
Spring cloud是一个基于Spring Boot实现的服务治理工具包，用于微服务架构中管理和协调各个服务的。
它利用 spring boot 的开发便利性巧妙地简化了分布式系统基础设施的开发，如服务发现注册、配置中心、消息总线、负载均衡、断路器、数据监控等，都可以用 spring boot 的开发风格做到一键启动和部署。
由于是微服务架构，由多个单体项目组成，就会有各自的通信地址，所以我们用服务发现注册Eureka来管理通信地址，配置中心config来管理配置文件并放到gitee上去保存，服务发现注册包含了服务端EurekaServer和客户端EurekaClient，(可以讲心跳机制)，微服务EurekaServer在启动时会将通信地址发给注册中心EurekaClient，形成通信列表，也就是服务注册；微服务从注册中心获取一份微服务通信地址，自己向别的微服务通过通信地址找到的该微服务通信地址基于HTTP发起请求叫做服务发现；
当有多个微服务时，根据业务需求可能会有多个服务者，也就是功能一样的两个模块。需要对他们发起的请求进行处理，所以我们需要负债均衡负载均衡Ribbon，通过负载均衡来控制请求的分发，负载均衡常用算法有轮询(公平，两个都一样),随机,加权轮询(哪个厉害点就多给点，能者多劳)。
但是一个服务出现延迟时，所有的请求都阻塞在依赖的服务，高并发的依赖失败时如果没有隔离措施，当前应用服务就有被拖垮的风险也就是雪崩，所以我们需要用到断路器Hystrix，将出现问题的服务通过熔断、降级等手段隔离开来，这样不影响整个系统的主业务，所以维护起来更方便。具体方式有：资源隔离（线程池隔离和信号量隔离），熔断（熔断，半熔断，闭合），降级（服务熔断后返回一个预先设定好的托底数据）；
当服务都能正常运行时，我们不能让所有都来访问，要有一个保安来拦截不该进来的请求，比如爬虫和其余不合法的请求，所以我们用到了服务网关Zuul，zuul还能自定义过滤器，比如自定义一个accesstoken，不带accesstoken的不让访问。有效的保证了服务的安全性。
https://blog.csdn.net/CSDN2497242041/article/details/120558219
https://blog.csdn.net/guorui_java/article/details/118095020
https://blog.csdn.net/qq_34416191/article/details/117927553
https://baijiahao.baidu.com/s?id=1666448276232778855&wfr=spider&for=pc
SpringBean的生命周期，大致可以分为五个阶段。分别是 创建前准备，创建实例化，依赖注入，容器缓存，销毁实例。
https://zhuanlan.zhihu.com/p/248493266
https://blog.csdn.net/weixin_46122805/article/details/115791088
首先所谓的事务传播行为是多个声明事务的方法，相互调用的时候，这个事务应该如何去传递。在Spring中有七种事务传播行为。
第一个是required，它是spring里面默认的事务传播行为，也就是说如果当前存在事务，就加入到这个事务里面去执行。如果不存在事务就新建一个事务。第二个是require_new，她不管说是否存在事务。它都会新开启一个事务来执行。新老事务是相互独立的。外部事务抛出异常，并不会影响内部事务的一个正常提交。第三个是nested，就是如果当前存在事务，就嵌套在当前事务中去执行。如果当前没有事务，那么就新建一个事务，类似require_new这样的传播行为。第四个是supports表示支持当前的事务，如果当前不存在事务，就以非事务的方式去执行。第五个是not support，它表示以非事务的方式来运行。如果当前存在事务，就需要把当前的事务挂起来。第六个是mandatory，它是一个强制的事务执行，就是如果当前不存在事务，就抛出一个异常。第七个是never，就是以非事务的方式去执行，如果当前存在事务，则抛出异常。Spring中的传播级别是一般不需要去定义的，默认就是required，除非是在嵌套的事务的情况下，需要去重点的了解。
嵌套回滚：https://www.cnblogs.com/yaowen/p/12579888.html
事务失效
@Transactional
public String insertUser(UserEntity userEntity) {
try{
userMapper.insertUser(userEntity);
int j = 1/0;
} catch (Exception e) {
// 此时事务注解失效，因为catch了异常，AOP容器捕获不到，不会回滚。
TransactionAspectSupport.currentTransactionStatuc().setRollbackOnly(); // 此时用此代码手动回滚;
}
}
https://blog.csdn.net/weixin_38361347/article/details/119057415
https://blog.csdn.net/Java___interview/article/details/120780629
==比较的是栈中的值（基本数据类型比较变量值，引用类型比较堆中内存对象的地址）
1.简述final的作用
最终的：
2.为什么局部内部类和匿名内部类只能访问局部final变量？
首先需要知道的一点是：内部类和外部类是处于同一个级别的，内部类不会因为定义在方法中就会随着方法的执行完毕就被销毁。
这里就会产生问题：当外部类的方法结束时，局部变量就会被销毁，但是内部类对象可能还存在（只有没有人再引用它时，才会死亡）。这里就出现了一个矛盾：内部类对象访问了一个不存在的变量，为了解决这个问题，就将局部变量复制了一份作为内部类的成员变量，这样当局部变量死亡后，内部类仍然可以访问它，实际访问的是局部变量的“copy”。这样就好像延长了局部变量的生命周期。
将局部变量复制为内部类的成员变量时，必须保持这两个变量是一样的，也就是如果我们再内部类中修改了成员变量，方法中的局部变量也得跟着改变，怎么解决问题呢？
就将局部变量设置为final，对它初始化后，我就不让你再去修改这个变量，就保证了内部类的成员变量和方法的局部变量的一致性。
场景：经常需要改变字符串内容时使用后面两个
优先使用StringBuilder，多线程使用共享变量时使用StringBuffer
重载：发生在同一个类中，方法名必须相同，参数类型不同，个数不同，顺序不同，方法返回值和访问修饰符可以不同，发生在编译时
重写：发生在父子类中，方法名，参数列表必须相同，返回值范围小于等于父类，抛出的异常范围小于等于父类，访问修饰符范围大于等于父类。如果父类方法访问修饰符为private则子类就不能重写该方法。
接口设计的目的，是对类行为进行约束（更准确的说是一种“有”约束，因为接口不能规定类不可以有什么行为），也就是提供一种机制，可以强制要求不同的类具有相同的行为。它只约束了行为的有无，但不对如何实现行为进行限制。
而抽象类的设计目的，是代码服用。当不同的类具有某些相同的行为（记为行为集合A），且其中一部分行为的实现方式一致时（A的非真子集，记为B），可以让这些类都派生于一个抽象累。在这个抽象类中实现了B，避免让所有的子类来实现B，这就达到了代码复用的目的。而A减B的部分，留给各子类自己实现。正是因为A-B在这里没有实现，所以抽象类不允许实例化出来（否则当调用到A-B时，无法执行）。
抽象类对类本质的抽象，表达的是is a的关系，比如： BMW is a Car。抽象类包含并实现子类的通用特性，将子类存在差异化的特性进行抽象，交由子类去实现.
而接口是对行为的抽象，表达的是like a的关系。比如： Bird like a Aircraft（像飞行器一样可以飞），但其本质上is a bird。接口的核心是定义行为，即实现类可以做什么，至于实现类主体是谁，是如何实现的，接口并不关心
使用场景：当你关注一个事务的本质的时候，用抽象类。当你关注一个操作的时候，用接口。
抽象类的功能要远超过接口，但是定义抽象类的代价高。因为每个类只能继承一个类。在这个类中，你必须继承或编写出其所有子类的所有共性。虽然接口在功能上会弱化许多，但是它只是针对一个动作的描述。而且你可以在一个类中同时实现多个接口。在设计阶段会降低难度。
SpringBoot启动流程的简化版代码
public static void run(Class<?> primaryClass) {
// 1.创建一个ApplicationContext实例，即我们常说的IOC容器
ApplicationContext context = createApplicationContext();
// 2.将主类（primaryClass）注册到IOC容器中（简单但重要的第一步）
loadSourceClass(context,primaryClass);
// 3.递归加载并处理所有的配置类
processConfigurationClasses(context);
// 4.实例化所有单例Bean（Singleton Bean）
instantiateSingletionBeans(context);
// 5.如果是Web应用，则启动Web服务器（例如Tomcat）
startWebServer(context);
}
