总结

怎么解决fullGC了

1. 开启GC日志
2. 分析最近上的代码
3. 使用工具查看内存，对应年轻代码，老年代
4. 分析是否有大对象创建，是否年轻代设置过小
5. dump文件，分析dump文件，查找对应的大对象或是大量创建的对象
6. 跟据这些信息跟踪程序

查询索引错误该怎么办

1. 走执行计划，看为什么选的索引
2. 优化sql,让索引大的先执行，比如联合索引时的最左原则
3. 强制指定索引
4. 重新设计索引，索引的拆分与合并

分布式锁加锁失败后的等待逻辑是怎么处理的

1. 加锁失败后有直接返回的，等待执行，阻塞等待的，指数等待的，通过消息接收等待的，指定睡眠时间重试的

分布式锁加锁失败后的等待逻辑是怎么实现的

1. 高并发场景：指数退避法
2. 公平性要求：阻塞队列或等待唤醒
3. 性能优先：简单重试+sleep
4. 防止死锁：超时时间+直接返回

分库分表中的数据倾斜严重该怎么处理

1. 分析为什么数据倾斜，是否有热点数据，热点数据具体原因具体分析
2. 分片是否设计合理，选择更合理的分片算法
3. 分片键+随机值打散
4. 重新选择分片算法，重新分片

spring的事务管理

1. 声明事事务，注解事务
2. 编程式事务，使用transactionTemplate去包
3. 事务管理机制transactionManager实现事务开启，提交，回滚
4. 事务传播机制，required：如果有事务，则加入没有则创建。
5. 事务回滚机制，指定异常回滚和RuntimeException自动回滚

事务有哪几种

1. 原子性，一致性，隔离性，持久性
2. 原子性：所有操作都必须是原子操作不可中断
3. 一致性：A账户+100 = B账户 - 100
4. 隔离性：两个事务执行时不允许相互影响
5. 持久性：事务执行完成后，一定要落到表里

redis热key解决方案

1. 多级缓存，在本地先缓存一层
2. 对热key进行随机数
3. 批量排队
4. 业务限流
5. 分布式多分片减少热key
6. 使用更高效的数据结构

spring如何解决bean的依赖

1. 三级缓存实现
2. Bean A依赖 Bean B，Bean B依赖Bean A，当实例化A时，把A放到三级缓存中，这时发现A依赖B，将B实例化时，发现B依赖A，将A从缓存中拿过来实例化完B，将B放到一级存中，再将A实例化完成后放到一级缓存中
3. scope 是 prototype时无法解决循环依赖问题

什么是重入锁，为什么需要重入锁

1. 当线程获得一个锁时，当这个锁的代码需要再去调一个同样获得该锁的方法时，如果这个锁不是重入锁，它将发生死锁。

线程死锁

volatile

1. 告诉编译器，每次取数据都从主内存中取。保证可见性，不保存原子性
2. count++也不保存原子性

synchronized保证原子性

1. 锁机制，在读取的时候就要等待操作完成后，才能读到值

java中如何实现cas操作

1. unsafe的native方法
2. 增加一个值，比较旧值，期望新值，返回true / false
3. ABA问题，版本号、时间戳

synchronized

1. 重量级锁
2. 新版本升级锁
3. 静态方法是class对象锁
4. 普通方法是实例锁

reentryLock重入锁

1. 与synchronized类似，只是更灵活
2. 可以指定锁类型，可中断锁

threadLocal是什么

1. threadLocal相当于是一个Map,key是当前线程名，value是泛型
2. 由于是key是当前线程名，sevlet线程池线程不回收，threadLocal就无法被回收的

创建线程池的核心参数

1. 核心线程数
2. 最大线程数
3. 队列
4. 拒绝策略
5. 线程数大于核心线程数时，空闲多久释放线程
6. 时间单位
7. 线程工厂

线程拒绝策略

1. 线程队列满了，再来新的任务时
2. 报错直接拒绝
3. 不丢弃，让调用者线程去执行
4. 不处理，直接丢弃
5. 丢弃最早的任务

AQS抽象队列器

1. 有个公共变量，如果变量没被占用，则当前线程为工作线程。如果被占用，需要有个队列将这些线程阻塞等待唤醒的机制。
2. 获取不到锁就放到等待队列中

Semaphore（信号量）

1. AQS中的公共变量是设定的，比如设定为5，那么5个工作线程分别获得共享资源后，后续的任务将进入队列等待
2. 停车场，10个停车位，来了10辆车后，后面的车就要等。10辆车出去后，把资源让出来，后面才能进新的车
3. Semaphore 更像是一个许可证，可以控制同时访问共享资源的线程数量。

CountDownLatch

1. AQS中公共变量设定，比如设定为5，当每个任务执行完后自动阻塞，调用countDown,变量减1，变量为0后，主线程再执行
2. 停车场里所有的车都离开了之后，才启动闸机。这个闸机就是CountDownLatch
3. CountDownLatch 更像是一个倒计时器，用于等待多个线程完成任务。

Bloom过滤器

1. 由多个hash函数散列到一个大的数组中
2. 能判断一个对象一定不在这个数组中
3. 判断一个对象在这个数组中不准确
4. 判定一个数是否在这个大数组中。黑名单、缓存的前一层过滤器

数据表外键

1. 不建议使用
2. 在大的数据下，触发级联更新，全阻塞式，更新数据会引发数据风暴
3. 分表不友好，无法建外键

myISAM

1. 全文检索型，快，不支持事务，只支持表级锁，最大的问题是崩溃后不能安全恢复
2. 不支持外键
3. 非聚簇索引，查询时要回表，多一次IO

mysql三大日志

1. binLog 归档日志
2. redoLog 重做日志，恢复数据
3. undoLog 回滚日志，事务回滚时的日志

redo log

1. 更新了数据，记录redo log
2. 事务提交，redo log刷盘
3. 记录的是数据变更
4. 事务提交前写入
5. 保证事务提交前崩溃时，能够把数据还原回来

binLog

1. 逻辑日志，记录数据变更的sql
2. 事务提交后写入
3. 同步数据

undo log

1. 逻辑日志，删除一条数据，记录一条insert sql
2. 回滚事务用的

redis 与 memCached

1. redis支持更多的数据结构
2. redis有容灾方案
3. redis支持原生集群方案
4. memCache是多路复用模型的多线程IO，redis 单线程IO

redis search

1. 小型搜索引擎
2. 数据限制
3. 聚合能力较差
4. 生态较差

redis 延时任务

1. redis延时消息事件
2. redis延时队列

zset原理

1. 多层链表，每一层是下一层的索引
2. 最底层包含所有元素，上一层是部分数据的索引，元素是被随机选为索引节点
3. 查询是从顶层开始，直到找到数据

zset结构

1. 跳表+hash
2. 跳表用来查范围和排序
3. hash用来记录分值

为什么使用跳表而不是二叉树

1. 删除、更新、查询都是logN，但平衡树需要自旋达到平衡
2. 算法更简单

HyperLogLog

1. 大数据估算，适合大数据
2. 数据不是精确值，但效率高

bitMap

1. bit位的累计值
2. bit位的范围查询

统计20亿用户统计多天的打卡总数

1. setbit key offset value
2. setbit 20241224 userId 1
3. bitcount 20241224
4. bitop

redis持久化机制

1. RDB AOF
2. RDB是某个时间点的快照，主从同步与重启恢复
3. RDB会阻塞线程 或 fork线程出来非阻塞执行
4. AOF默认更新一条数据，就写一条数据到缓冲区，再跟据磁盘策略刷盘

AOF

1. AOF是命令提交成功后再写，与mysql不一致
2. 不阻塞redis命令

pipeline与mulit命令区别

1. pipeline是一次IO，多次执行，减少IO
2. pipeline非原子，上次执行结果不影响后面执行结果
3. mulit是多次IO，统一exec，原子操作

大key

1. String超过1M
2. 集合超过5000
3. bigKey查大key
4. 在从库查，避免阻塞

redis高可用

1. 主从复制
2. 哨兵模式，主从模式下的高可用
3. 集群模式，hash槽

synchronized 底层原理

1. monitor entry exit
2. 获得对象锁计数器加1
3. exit后，计数器减1
4. 方法级别的不需要monitor entry 和 exit，只需要共享变量

为什么读锁不能升级成写锁

1. 读锁是共享锁
2. 写锁是独占锁
3. 会产生死锁，前提是需要对方先释放锁

线程池工作原理

1. 创建线程池时需要设定最小线程数，最大线程数，队列大小等
2. 任务提交时，核心线程处理对应的任务
3. 核心线程处理不及时时，放入队列
4. 队列满了，激活最大线程
5. 最大线程也处理不过来且队列又满了时，触发拒绝策略

JVM内存模型

1. 堆、栈、本地内存

堆

1. 所有对象创建时都在堆中
2. 字符串常量池

栈

1. 方法创建时的局部变量存在栈中
2. 部分外部没有引用也不返回的局部对象存在栈中

java回收机制

1. java把内存分为逻辑块 eden、S0、S1，老年代
2. 创建对象时先放入eden区，当eden满了，触发minorGC
3. 将还有引用的对象放入S0,计数+1
4. 当S0满了，将S0 miniorGC后，复制到S1，计数+1
5. 直到计数超过设定值后，没有被GC的对象复制到老年代
6. 老年代内存快满时，触发majorGC，触发stop world
7. 新晋升的对象无法放入老年代时，触发FullGC

CMS 、G1、ZGC

1. CMS标记清除，碎片化严重
2. G1,配置复杂，需要经验
3. ZGC,需要更高的版本,java11

tomcat为什么需要打破双亲委派

1. tomcat需要加载多个应用程序，每个应用程序中的类可能因为版本不同而不同
2. 相同版本的类库需要共享复用
3. tomcat是个容器，它有自己的类库，需要优先保证自己的类库优先加载和不被替换
4. jsp等修改后，要能够自动加载，肯定需要重写类加载器

滑动窗口

1. 固定时间内允许放出固定数的令牌，令牌数不累计
2. 整个窗口期内，流量一定不会突破上线
3. 令牌桶则是在固定时间放出固定数的令牌，令牌数累积

redis宕机了，如何保证数据恢复

1. RDB & AOF
2. RDB是快照，记录某一个时刻的数据
3. AOF记录的是数据更新sql，并且记录速度更快更频繁

缓存穿透、击穿、雪崩

1. 穿透：没有缓存。缓存Null或本地缓存或boolom过滤器拦截
2. 击穿：有缓存，热key失效时，大量请求打到数据库。在读数据库时，加锁
3. 雪崩：大量热key同时失效，造成数据库瞬间被打跨。避免热key同时失效，加锁

一致性hash是什么

1. 一致性hash是将hash列表以环链的形式存在
2. 将每个服务器以节点的形式映射到环上
3. 作用是新加入的节点只需要在环上注册一个节点，并且将少量上就近节点的数据移到新节点上
4. 解决节点增加与减少时，全量数据rehash的情况

redis为什么不使用一致性hash

1. 因为redis提供了更高级的hash槽概念
2. 默认为1万6的槽位，每个服务器接管一部分hash槽
3. 每当有机器新加入时，只需要计算并接管部分hash槽
4. 可以理解为hash槽是一致性hash的二级索引加持
5. 有了这个二级索引，查数更快，映射内容更方便，数据节点容错与恢复更简单

B树与B+树

1. B树任何节点都存数据，B+树只有叶子节点存数据
2. B+树叶子节点是有序链表
3. B树查询多条数据时，需要跨索引节点找。B+树可以按链表查
4. B树高，B+数10亿内是3层，超过则4层

排查cpu过高

1. 外部，是不是请求过高
2. 内部，查找高cpu的服务,top命令
3. 锁问题，排查是否有死锁或大量锁竞争 jstack
4. IO问题，排查是否有大量的读写操作或网络IO
5. 使用arthas排查调用次数、IO、耗时，cpu使用过高的线程
6. 算法问题，实现的算法执行过多

jvm 内存模型

1. 方法区：主要放类的定义，常量和一些编译后的代码，可以理解成元数据区
2. 堆：java对象与数组创建存放的区域，GC主回收阵地
3. 本地方法栈：native方法栈
4. 虚拟机栈：方法调用时创建的栈，包含局部变量的创建和各种对象引用等，方法调用的入栈出栈
5. 程序计数器：用来存代码执行行数的一小块内存

垃圾回收

1. 标记清除：先标记哪些是活动对象，再清除未被标记的对象
2. 复制算法：把标记为活着的对象复制到新的内存中，其他的全部清除
3. 分代收集：新生代使用

为什么rocketMq能保证消息的顺序

1. rocketMQ在底层是以消费者组的形式按顺序写入磁盘，所以，它的写是非常快的
2. 读顺序因为只有一个group,虽然每次读都要2次IO，但实际上读也是按顺序读的
3. kafka则因为写的时候按分片写入，虽然分片是顺序写，但多个分片是独立的，所以永远无法保证数据是全量顺序写