JVM——执行引擎为什么说JAVA是“半编译半解释型”语言？ JVM的编译器 Client Compiler（C1）：注重启动速度、局部优化 Server Compiler（C2）：注重全局优化 JVM的分层编译 层级0：解释器 层级1：C1编译器+轻量级优化 层级2：C1编译器+完整优化 层级3：C1编译器+分析数据收集 层级4：C2编译器

JVM——运行时数据区 运行时数据区包含：PC寄存器、本地方法栈、虚拟机栈、堆、元数据区、CodeCache 1. PC寄存器存储下一条指令的地址（线程私有） 不存在StackOverflowError和OutofMemoryError 2. 本地方法栈管理本地方法的调用（线程私有） 存在StackOverflowError和OutofMemoryError 3. 虚拟机栈线程私有，内部保存一个

JVM——类加载器子系统 类加载器子系统：负责从文件系统/网络中加载class文件 1. 类加载器分类 启动类加载器Bootstrap ClassLoader 扩展类加载器Extension ClassLoader 系统类加载器AppClassLoader 用户自定义加载器 除Bootstrap CLassLoader，其他类加载器都继承于ClassLoader 2. 双亲委派机制

Redis哨兵1. 投票1：判断主服务器是否下线哨兵集群中的一个哨兵判定主节点下线后**（主观下线），会发起投票，若多数哨兵都认为主节点下线，则为客观下线**，需要切换主节点。 2. 投票2：选举leader哨兵切换主从节点需要一个哨兵来做，这个哨兵称为leader哨兵，需要经过推选得到。 3. leader哨兵进行主从切换 选出新主节点：先排除已离线的从节点，再排除网络状况不好的从节点，剩下的从

Redis主从复制1. 第一次同步（全量复制） 建立主从服务器连接 同步数据：主服务器执行bgsave生成RDB文件，发送给从服务器，从服务器加载RDB文件 在同步数据过程中新生成的写操作命令会被记录到从服务器的replication_buffer缓冲区，待从服务器加载完RDB文件后，执行这些写操作以实现主从一致。 如果同步数据过程太长导致replication_buffer缓冲区满了，则重

Redis过期删除与内存淘汰1. Redis过期删除策略1.1 惰性删除不主动删除，访问key时再判断是否过期，是否需要删除（节省cpu，但是占内存） 1.2 定期删除一段时间（每秒10次）随机抽20个key检查，将过期的删除，若过期数量超25%即5个，重复前面流程再来一次。 2. Redis内存淘汰策略2.1 不主动淘汰不主动淘汰，当内存满了还想添加数据则报错 2.2 在有过期时间的key中淘汰

Redis持久化1. AOF日志1.1 AOF日志在Redis执行完一条命令后，将该命令记录到AOF日志中 为什么是在执行完命令之后记录日志呢？ 避免额外的检查开销，AOF 记录日志不会对命令进行语法检查； 在命令执行完之后再记录，不会阻塞当前的命令执行。 这样也带来了风险： 如果刚执行完命令 Redis 就宕机会导致对应的修改丢失； 可能会阻塞后续其他命令的执行（AOF 记录日志是在 Re

Redis数据结构 引用：小林coding、JavaGuide 1. Redis是如何实现键值对数据库的？Redis是使用了一个哈希表保存所有键值对，哈希表其实就是一个数组，数组中的元素叫哈希桶。哈希桶存放的是指向键值对的指针（dictEntry*），键值对则保存了key和value的指针。 特别说明下，void * key 和 void * value指针指向的是Redis对象，Redis中

Kafka工作原理 1. Kafka核心概念 Message（消息）：Kafka中的数据单元称为消息。可以将消息看成是数据库中的一条“数据行”或一条“记录”。消息是Kafka中最基本的单位，每一条消息都是一个独立的记录，包含消息的键、值、时间戳等信息。 Batch（批次）：为了提高效率，Kafka将消息进行批量处理。消息被分批写入Kafka，这种方式提高了吞吐量，但也会增加响应时间。批次处理使得

为什么Integer用==比较时127相等而128不相等？ 引用：https://zhuanlan.zhihu.com/p/368421654 一、问题引出1234567public static void main(String[] args) { for (int i = 0; i < 150; i++) { Integer