fancyfor的博客

网易后端一面，场景题

本文对比了三种常见限流算法：计数器（固定/滑动窗口）仅关注请求数量，易受临界突刺影响；漏桶算法通过恒定速率输出，实现流量整形，保护下游但响应延迟高；令牌桶则允许突发，空闲时攒令牌，兼顾平滑与效率，适合大多数场景。三者本质区别在于对突发流量的处理策略，选择应基于业务需求。

本文总结了Redis 7.0+常见面试问题，重点分析了五种基本数据类型的底层实现与使用场景。String使用SDS实现，支持O(1)长度查询和动态扩容；List采用quicklist结构，结合了链表与listpack的优势；Hash存储小对象使用listpack，大对象使用hashtable；Set在元素较少时使用intset，否则转为hashtable；ZSet通过listpack或skiplist+dict实现有序存储。文章详细解析了SDS、listpack、quicklist等核心数据结构的特点，并对

本文对比了Java和Go语言在遍历集合时删除元素的差异。Java通过fail-fast机制(基于modCount和expectedModCount计数器)在检测到并发修改时会立即抛出ConcurrentModificationException异常，避免数据错乱。而Go语言由于设计哲学追求轻量，其range循环没有内置这种检查机制，需要开发者自行注意迭代安全。文章详细剖析了Java fail-fast的实现原理，解释了为何不能直接使用集合的remove方法而必须通过迭代器的remove操作，并提供了正确的删

这篇文章分析了双重检查锁定(DCL)实现单例模式时存在的问题及解决方案。关键点包括：1. DCL存在指令重排序隐患，可能导致返回未完全初始化的对象；2. 问题根源在于new操作的非原子性及可能的1-3-2执行顺序；3. 两种解决方案：使用volatile禁止重排序，或采用更优雅的静态内部类/枚举实现。静态内部类通过类加载机制保证线程安全，枚举则能防御反射和反序列化攻击。文章通过字节码层面解释了问题本质，并提供了代码示例说明解决方案。

摘要：SpringBoot自动配置基于"约定优于配置"原则，通过@EnableAutoConfiguration注解和条件加载机制实现。其核心流程为：读取META-INF下的配置文件加载候选配置类，利用@Conditional系列注解进行过滤，最终将符合条件的配置类注册到IOC容器。配置参数通过@ConfigurationProperties绑定到JavaBean，支持YML文件覆盖默认值。自动配置类通过SPI机制发现，SpringBoot2.x读取spring.factories，3.

核心线程数(固定不销毁)、最大线程数(阻塞队列满了之后创建临时救场的线程，用完就销毁|最大线程数=核心线程数+临时线程数)、阻塞队列(暂时存储任务，决定线程池吞吐能力)、拒绝策略(阻塞队列满了而且最大线程数也到了，对后续的任务所采用的策略)

Redis采用哈希槽（Hashslot）机制实现数据分片，将存储空间划分为16384个固定槽位，通过CRC16算法计算Key的槽位值。相比一致性哈希的直接Key-Node映射，Redis采用Key-Slot-Node两级映射，通过人工指定槽位分配实现更灵活的负载均衡。一致性哈希存在数据倾斜风险且扩缩容困难，而哈希槽以固定槽位为单位进行数据迁移，边界清晰且元数据同步开销小。Redis选择哈希槽机制主要因其更适合有状态分布式数据库场景，能保证数据安全性和扩展性，而一致性哈希更适用于无状态负载均衡场景。

B树和B+树在数据结构设计上存在显著差异。B树所有节点都存储数据，查询性能不稳定，且范围查询效率低；而B+树只有叶子节点存储数据，非叶子节点仅存储索引键，通过双向链表连接叶子节点，使得查询性能稳定、范围查询高效。B+树通过牺牲非叶子节点的存储空间换取更高的扇出率，将树高压缩到3-4层，大幅减少磁盘IO次数。这种设计使B+树特别适合数据库等需要频繁读写和范围查询的场景，成为主流数据库索引结构的首选。

• 引用计数：每次引用计数一下，没有引用就可以释放(需要添加额外的逻辑来处理循环依赖引用)→Python• 可达性分析：从ROOT对象开始搜索，搜不到的就都可以回收→Java。

Collection（存储单一元素）和Map（存储键值对）。