spring task
spring cloud实现原理
类的加载过程，类加载器是什么东西，有几种类型
jvm调优
选择jvm版本，client、server
堆区大小的指定
合理的选择收集器
小工具
jps.ext：打印jvm进程（对比linux的PS打印linux进程），如：jps -l -v
jstat.exe：查看jvm运行时信息，如查看jvm进程的gc信息，100毫秒一次，循环打印20次：jstat -gc pid 100 20
jvisualvm：最欠打的运行监视和故障处理工具，可以监控内存泄漏跟踪垃圾回收，执行内存分析，cpu分析，线程分析
记得添加Visual GC插件，更加清晰
jvm参数
内存参数
-Xms：初始堆大小，包括年轻代和老年代
-Xmx：最大堆大小
-XX:NewSize=n：设置年轻代大小
-XX:NewRatio=n：年轻代和老年代的比值
-XX:SurvivorRatio=n：年轻代中Eden与两个SurvivorRatio的比值
-XX:MaxPermSize=n：设置持久代的大小
收集器参数
-XX:+UserSerialGC:设置串行收集器
-XX:+UseParallelGC:设置并行收集器
-XX:+UseParalledlOldGC:设置老年代并行收集器
-XX:+UseConcmarkSweepGC:设置老并发收集器
......
备注
实际中，设置堆初始内存-Xms，堆最大内存-Xmx，新生代内存-Xmn；新生代和老年代1:2或1:3
尽量让对象留在新生代，因为老年代是Full GC，比较耗费性能
远程监控jvm
jststd：服务端执行jstatd，然后本地用jvisualvm客户端添加远程主机就可以了（可以使用visual GC插件，推荐用）
jmx：需要对每个jvm虚拟机添加启动参数（可以看cpu）
性能调优监控工具
jinfo 查看java应用程序参数
jstat 查看堆内存各部分使用量、类加载数量
jmap 查看内存，排查内存溢出，内存泄漏
jstack 查看线程状态，排查死锁
jvm构成
类加载器；
方法区（类加载后进入，字段，方法，常量池）
堆内存（实例），本地内存（jvm之外的内存区域）；
方法栈（局部变量，参数），本地栈（操作系统相关的操作）；
垃圾回收系统；
执行引擎
jvm内存分代
提高内存分配和垃圾回收效率
新生代：可以频繁gc，回收大部分内存，新生代复制到老年代的过程还能起到消除内存碎片的作用
老年代：多次垃圾回收存活下来的对象，gc频率相对较低
永久代：几乎不做gc
垃圾回收算法
引用算法；被引用则计数加1，计数为0则会被回收
复制算法：把内存分成两块相等的空间，遍历所有对象，把正在使用的对象复制到另一块内存，同时可以整理内存碎片
标记清除：☆从根节点开始标记被引用的对象，然后把未标记的对象删除，缺点是需要暂定应用，且会产生内存碎片
标记整理：☆结合了复制算法和标记整理算法，即执行标记清除后，再把对象按顺序排放（注意不是放到另一块内存区域）
垃圾回收器
垃圾回收流程
新生代在一次垃圾回收开始时，新生代中只有Eden和S0中有对象，垃圾回收器会把Eden中的大部分对象回收，剩下的会全部进入S1，S0中的对象会根据是否达到计数器（没躲过一次GC的对象计数加1）的阈值，一般是15，
如达到阈值则进入老年代，否则进入S1，最后会把S0和S1交换，另外如果S1空间不足后，也会自动转移到老年代；这样结束后，还是只有Eden和S0有对象；
老年代的GC频率相对较低，回收速度也会慢
大类
次收集器：年轻代空间紧张时会触发，间隔时间短
全收集器：老年代或持久代空间满了会触发，可使用System.gc()显示启动全收集
细分
新生代收集器
serial串行收集器：需要暂停用户线程，也叫Stop The World，新生代用复制算法，老年代用标记整理算法
ParNew并行收集器：利用了服务器多核，serial的升级版，缩短了SWT时间，还是存在SWT的问题
Parallel Scavenge：关注的不是收集时间，关注的是吞吐量
老年代收集器
serial old：类似serial
Parallel Old：类似Parallel
CMS收集器：☆真正的并发收集器，最短的SWT时间
G1收集器：可以用在新生代和老年代
JMM内存模型
jvm同步锁相关，同步机制，锁升级原理
hashmap hashtable hash碰撞
采用一种拉链发解决冲突，也就是如果hashCode相同，还会调用equals方法，进而确定位置
java文件怎么从磁盘一步步加载到jvm内存里面
手写单例，其他实现
spring，Mybatis（基本都是mybatis），spring boot jpa，spring boot，sharding-jdbc
redis，memcache
activemq，rocketmq，kafka（问的比较多，如怎么保证消息顺序性）
如何实现的百万级消息吞吐,kafka实现
mysql事务隔离级别
脏读：可以读取别人未提交的数据
不可重复读：主要针对更新一条数据，如事务A读取了一条数据后，事务B对该数据进行了修改，此时事务A再次读取时发现数据不一致；解决办法是事务A读取数据后，对单条数据进行锁定，防止事务B改变改条数据;这里强调单条数据的修改
幻读：主要针对插入和删除，如事务A按某个条件查询了一批数据，事务B对条件中的一个数据执行了新增或者删除，此时事务A查询的数据就和数据库不一致；解决办法是锁定整个表;这里强调的是多条数据
读未提交：存在脏读、不可重复读、幻读三个问题
读已提交：解决了脏读
可重复读：解决了脏读和不可重复读
串型化：解决了所有问题，效率最低
mysql索引原理，怎么实现的
B+树
从二叉查找数延伸，二叉树原理？二叉树也有局限性，就是近端情况下，高度太高，所以有了平衡二叉树，红黑树是一种不完全的平衡二叉树
每个想象成一个磁盘块；每个节点中数据量由阶数决定；非叶子节点只有指针索引信息；查询速度由树的高度决定，B+树高度固定；由于叶子节点是全量数据且有序，所以范围查找会很快；
SQL优化
不要用select *，因为查当行记录是耗时的，同步无法应用覆盖索引；
where尽量不用null值判断，因为会不走索引导致全表扫描；
使用联合索引的时候，遵循左侧前缀法则，常用的放左边
MongoDB索引怎么实现的，和mysql的区别
mongodb使用B-树，而mysql使用B+树；
B-树所有节点都存数据，可以遍历更少的节点就可以获取数据，关系型数据库范围查找的场景不多
B+树只有叶子节点存储数据，且所有叶子节点是有顺序，且每个叶子都通过指针相连接，所有范围查找会很快
mongodb的数据库分片，理论上库表大小没有上限，达到10G有略微性能下降，适用于数据结构不统一的海量数据业务，如用户评论，第三方抓取的数据，监控数据
sql性能调优，mysql执行计划怎么看
mysql如何主从同步，大概的实现方法
数据库分库分表怎么做
分布式锁
分布式事务（创建订单，扣减库存）
lombok实现原理
理论：开闭原则
linux部署命令
jps -l 查看java进程
kill -9 pid 杀进程
nohup java -jar ruoyi-admin.jar > /dev/null 2>&1 & 部署后台进程
spring mvc
spring可以创建父子容器，子可以访问父，父不可以访问子，如ContextLoaderListener创建dao、service，DispatcherServlet创建controller，则springmvc可以访问dao、service
流程
DispatchServlet：接受请求的顶级前端控制器
HandlerMapping：根据请求uri返回方法调用链，包含拦截器
HandlerAdapter：类似把请求适配到servlet上面去执行
Handler：后端控制器，也就是用户写的controller，一个handler对象处理所有请求，所以是线程不安全的，也就是controller中定义实例变量也是不安全的，经测试这一点和asp.net webapi不同
ViewResolver
spring
lookup-method:通过配置的方式，自动使用cglib动态实现抽象方法，创建子类型，是工厂方法的扩展
spring aop表达式
execution：最通用的
target：目标对象
this：通知对象
whitin：包名
args：参数
mybatis插件
Interceptor：数据权限过滤、分页、sql执行时间性能监控，使用场景不多，市场用的多的只有PageHelper
generator：自动生成mapper配置文件和mapper接口
SpringBoot
推荐是用java配置的方式注入，@Configuration、@Bean
最佳实践：aop和基础配置用xml，业务类用注解
@PropertySource：读取外部资源文件，@PropertySource(value={"classpath:jdbc.properties"})，使用@Value("${jdbc.url}")获取配置
@ImportResource：有些时候，需要导入自己的xml配置文件：@ImportResource({"classpath:some-context.xml"})
优点：约定大于配置；整合主要的第三方组件，并且提供了默认配置，如果我们自己提供了配置实现，默认的配置就不生效（@ConditionalOnClass）
排除自动配置：@SpringBootApplication(exclude = { DataSourceAutoConfiguration.class })
自动配置原理：初始化的时候会加载spring-boot-autoconfigure.jar/META-INF/spring.factories文件的自动配置类，将配置的对象载入spring容器
@ConfigurationProperties(prefix = "spring.redis"):读取此配置前缀的配置
@EnableConfigurationProperties(RedisProperties.class)：如果一个配置类只配置@ConfigurationProperties注解，而没有使用@Component，那么在IOC容器中是获取不到properties 配置文件转化的bean，而引用时使用@EnableConfigurationProperties注解后可以生效，可以看下自动配置的代码，都是这样实现的
自定义配置静态资源路径
默认的静态资源路径有4个：classpath:/META-INF/resources/，classpath:/resources/，classpath:/static/，classpath:/public/
默认是在classpath下，如果是用户上传的大文件路径，一定不能放到classpath下，需要指定另外一个路径
添加下面3行配置，相当于把项目外部的一个路径制定为静态资源路径，springboot会挨个路径寻找资源
web.upload-path=d:/Crm/uplaod/
spring.mvc.static-path-pattern=/** 表示子目录及里面的子目录，/*只表示下一级
spring.resources.static-locations=classpath:/META-INF/resources/,classpath:/resources/,classpath:/static/,classpath:/public/,file:${web.upload-path}
自定义消息转化器:注入StringHttpMessageConverter对象即可，如：修改返回值编码格式、修改json转换器
自定义拦截器：继承WebMvcConfigurerAdapter，并重写addInterceptors方法,然后把重写HandlerInterceptorAdapter的拦截器添加进来，就实现了拦截器
自定义消息转化器也可以在这里实现
编译器提示已经过时,新的方案是继承：WebMvcConfigurer或WebMvcConfigurationSupport
整合servlet两种方式:注解扫描继承HttpServlet，@ServletComponentScan；ServletRegistrationBean
整合Filter两种方式：注解扫描继承Filter，@ServletComponentScan；FilterRegistrationBean
整合Listener两种方式：注解扫描继承ServletContextListener,@ServletComponentScan；ServletListenerRegistrationBean
Filter和Interceptor
Filter是作用在Servlet前,Interceptor执行在Action前
Filter前处理 --> Interceptor前处理 --> action --> Interceptor后处理 --> Filter后处理
如果要用到spring相关的组件，用Interceptor
概念：listener，filter，servlet，interceptor
监听器(listener)：就是对项目起到监听的作用，它能感知到包括request(请求域)，session(会话域)和applicaiton(应用程序)的初始化和属性的变化；
应用：获取当前在线人数
过滤器(filter)：就是对请求起到过滤的作用，它在监听器之后，作用在servlet之前，对请求进行过滤
应用:编码转换、日志记录，比如记录所有对网站发起请求的地址、登陆判断
servlet是对request和response进行处理的容器
拦截器(interceptor)：就是对请求和返回进行拦截，它作用在servlet的内部
Spring的配置文件应该扫描service层及以下，SpringMvc的配置文件应该扫描controller层； 我们在service层如果想做日志的话，可以使用spring aop特性，在spring.xml中配置aspect即可，那么如果想在controller层做日志，相应地，在SpringMvc.xml中配置
redis，httpclient，rabbitmq整合
rabbitmq,kafka区别和取舍
用kafka作为消息传输的数据管道，用rabbitmq作为交易数据传输管道，rabbitmq在金融场景中经常使用，数据丢失的可能性更小
而kafka优势主要体现在吞吐量上，虽然可以通过策略实现数据不丢失，但从严谨性角度来讲，大不如rabbitmq
