线程池（）用于复用线程、控制并发度、管理任务队列和生命周期，从而提升性能并避免频繁创建/销毁线程的开销。线程池分为核心线程池线程池的最大容量等待任务的队列，提交一个任务，如果核心线程没有满，就创建一个线程，如果满了，就是会加入等待队列，如果等待队列满了，就会增加线程，如果都达到最大线程数量，就会按照一些丢弃的策略进行处理。提交任务 → 核心线程是否已满？├─ 未满 → 创建核心线程执行└─ 已满

Scheduler 是“定时去查”，RabbitMQ 延迟插件是“到时通知你”。

你这个场景特别典型：文章发布后，要做 3 件事：更新 ES 索引清理缓存发送通知。

同一个线程拿到锁后，可以再次进入被同一把锁保护的代码。，使用简单，JVM 自动加锁和释放锁；不支持这些高级特性。所以现在一般不能简单说谁性能一定更好。获取锁失败后，只能一直阻塞等待。优点是语法简单，不容易忘记释放锁。、可中断获取锁、公平锁，以及通过。你面试时主要说这 5 点就够了。这在生产者消费者模型里更灵活。所以本质上，它们都是为了解决。：尝试获取锁，拿不到直接返回。但从 JDK 1.6 以后，

在微服务里，服务实例很多，而且 IP、端口可能会变。如果服务 A 想调用服务 B，不能把地址写死。服务启动时，把自己的 IP、端口、服务名注册到注册中心，这叫服务注册服务消费者调用时，先去注册中心查有哪些可用实例，这叫服务发现拿到实例列表后，再通过 Ribbon、LoadBalancer 之类做负载均衡调用同时，注册中心一般还会通过心跳机制判断实例是否存活，不健康的实例会被摘除。Eureka 和

Nacos 官方也把自己定位成“动态配置服务”，强调配置的中心化、外部化和动态化管理。

自定义一般就是自定义或Filter。官方开发者文档里也提供了扩展和自定义过滤器的方式。

你就把 Kafka 想成这样：Topic 是仓库分类区Partition 是货架Producer 往货架上放货Consumer 从货架上拿货副本就是同样的货架再备份几份Leader 是当前负责对外服务的主货架主货架坏了，备份货架立刻顶上。

寄快递的人：收快递 / 处理快递的人：快递柜：分拣中心：快递单上的地址标签：整个 RabbitMQ 服务器。

String 不可变主要是因为它底层字符数组在设计上不允许被随意修改，同时类本身也被 final 修饰，防止被继承后破坏这种特性。不可变的好处有几个：第一，线程安全；第二，可以安全地作为 hash key；第三，便于常量池复用；第四，也有利于安全性，比如数据库连接串、类加载等场景都更可靠。因为 0.75 是时间和空间上的一个折中。负载因子太小，会导致数组空位很多，浪费内存；太大则会让桶里元素太多，