- 博客(648)
- 资源 (2)
- 问答 (1)
- 收藏
- 关注
RSS订阅原创 求解深分页问题,last pk适合什么情况
MySQL深分页性能问题及解决方案 摘要：MySQL深分页（如LIMIT 1000000,10）会导致扫描大量无用数据，性能极差。解决方案推荐"last pk"（滚动分页/寻路法），利用索引有序性直接定位下一页起点（WHERE id>1000000 LIMIT 10）。该方案适用于流式展示（如社交媒体）、大数据迁移等场景，但不支持随机跳页。对于必须跳页的情况，可采用延迟关联（先查索引再回表）或限制最大翻页数。last pk是解决深分页性能问题的有效方案，但需根据业务场景（是否需跳页
2026-05-11 22:53:01
171
原创 细说DCL单例模式和volatile有什么关系,volatile在DCL中是必要的吗??
摘要： DCL（双重检查锁定）是Java实现线程安全单例的高效方式。标准代码通过两次if检查兼顾性能与安全：外层避免无谓锁竞争，内层防止重复创建。关键点在于volatile修饰实例变量，禁止new操作的指令重排序（1-3-2乱序），避免返回未初始化的"半成品对象"。其底层通过内存屏障和Happens-before规则（volatile写读顺序+传递性）确保线程安全。面试需强调：仅synchronized无法保证有序性，volatile解决了重排序引发的可见性问题。（149字）
2026-05-11 11:09:33
350
原创 Spring Cloud 为什么需要服务注册与发现中心这些东西？
微服务架构下，服务注册与发现中心解决了分布式系统的动态寻址问题。传统硬编码IP的方式面临扩容困难、高可用失效和端口管理混乱三大痛点。注册中心通过自动服务注册（实例启动时上报地址并维持心跳）和服务发现（调用方实时获取可用实例列表），实现了：1）自动健康检查，剔除故障节点；2）动态扩缩容，无需人工干预；3）逻辑服务名与实际地址解耦。其本质是一个带健康检查的动态数据库，替代了人工维护IP列表的工作，通过客户端组件自动完成心跳和列表同步，使微服务架构具备弹性伸缩能力。
2026-05-09 22:25:13
229
原创 容器是怎么管理 Bean 的？
摘要：Spring容器通过BeanDefinition（配置蓝图）和BeanFactory（生产工厂）管理Bean生命周期，包含四个阶段：准备实例化→装配填充→初始化→生存销毁。核心机制包括三级缓存解决循环依赖问题，以及BeanFactory与ApplicationContext的功能对比（懒加载vs预加载）。容器本质是利用反射+缓存实现自动化组装，通过生命周期接口提供扩展性。文章最后引出单例模式在高并发场景下的潜在问题思考。（149字）
2026-05-09 21:58:47
290
原创 Bean 会被 JVM 回收吗？
摘要： Spring Bean能否被JVM回收取决于其作用域和引用可达性。单例Bean的生命周期由Spring容器管理，容器关闭前因强引用存在而无法回收；多例Bean创建后即与容器解耦，回收时机由业务代码决定。两者均需满足容器断开引用和业务代码无强引用才会被GC回收。单例Bean若持有大对象（如百万级数据的ArrayList）会导致内存长期占用，可能引发内存泄漏或性能问题。核心结论：Bean回收本质遵循JVM可达性规则，仅当完全“不可达”时才会被回收。
2026-05-09 21:50:33
372
原创 Bean 什么时候会被销毁？
摘要 Spring Bean的销毁时机取决于作用域和容器状态。单例Bean在容器关闭时销毁，多例Bean由开发者自行管理，Request/Session作用域Bean分别在请求/会话结束时销毁。销毁顺序为：@PreDestroy方法 > DisposableBean接口 > 自定义destroy-method。常见问题包括未优雅关闭容器导致单例Bean未销毁，以及多例Bean需要手动销毁。不同作用域的Bean生命周期管理策略差异显著，开发者需根据具体场景正确处理资源释放。
2026-05-09 21:49:48
236
原创 传统 Spring XML 配置 vs Spring Boot Starter 对比文档
本文对比了传统Spring XML配置与Spring Boot Starter在数据源配置、MyBatis集成和Bean管理方面的差异。传统方式需要手动配置数据源Bean、SqlSessionFactory和每个DAO Bean，依赖XML文件和属性文件；而Spring Boot通过starter自动配置，只需简洁的YAML配置，支持注解方式开发，大幅简化了配置工作。Spring Boot的自动扫描和依赖注入机制取代了繁琐的XML Bean声明，使开发更高效。
2026-05-09 17:34:27
321
原创 那我怎么样才能让Claude Code在写sprinboot代码的时候按照TDD for AI的方式去执行啊??
要让AI在Spring Boot项目中落地TDD开发，需通过配置文件约束、环境集成和指令诱导三管齐下。关键是在项目根目录创建claude.md文件，明确规定TDD流程：测试先行、红灯运行、最小实现、绿灯验证和重构。同时确保AI能操作终端运行测试命令，并通过精准指令引导AI按TDD步骤开发。针对Spring Boot项目，还需加入特殊校验技巧如JsonPath校验、数据库回滚和依赖模拟。这种模式下，开发者角色转变为审核AI生成的测试用例，确保代码质量。
2026-05-08 12:37:30
324
原创 什么是TDD for AI,详细讲一下
简单来说，TDD for AI就是在让 AI（如 Claude Code, Cursor, GPT-4）编写逻辑代码之前，先由人工或 AI 定义好自动化测试用例。需求 -> 人写代码 -> 人写测试 -> 运行。需求 ->定义测试（断言结果）->AI 生成代码->自动运行测试->AI 根据报错自修复-> 成功。它是将 AI 从一个“概率性文本生成器”转化为“确定性工程工具”的核心。开发者不直接写代码，而是写下测试脚本（如 Jest, Pytest）。
2026-05-08 12:28:54
427
原创 做一个Agent,完整的搭建流程是什么
AI Agent构建全流程指南 本文系统性地阐述了从零搭建AI Agent的四个关键阶段和八个核心步骤。第一阶段聚焦需求定义与基座选择，强调场景边界划定和适配合适的大模型。第二阶段进入核心组件构建，包括提示词工程、工具集成和记忆系统设计。第三阶段涉及工程化落地，推荐使用现成框架处理编排和异常控制。最后阶段强调可观测性和持续优化，通过专业工具追踪Agent决策过程。整个流程兼顾理论范式与实践落地，覆盖了从概念验证到生产部署的全生命周期，为开发者提供了清晰的AI Agent工程化路径。
2026-05-07 13:57:14
148
原创 在 ReAct 模式中，如何处理重试以及防止死循环？有哪些标志位可以判断？
摘要： ReAct模式通过“思考-行动-观察”循环解决问题，但易因模型随机性或工具调用问题陷入逻辑死循环或无效重试。构建健壮系统的核心策略包括：1）硬性约束（如最大迭代次数、重复检测）；2）状态感知（通过标志位监控迭代、错误、相似度等）；3）反馈修正（带上下文的重试、工具降级、反思提示）。实践建议包括系统提示约束、人工介入点和结构化输出。最终需权衡硬性限制与动态调整，确保代理在复杂任务中的确定性和效率。
2026-05-07 01:41:31
221
原创 Single-Agent 与 Multi-Agent 的优劣势分别是什么？什么场景适合 Multi-Agent？
摘要： Agent架构设计需在**Single-Agent（高效扁平）与Multi-Agent（分治协作）**间权衡。 Single-Agent适合简单任务，优势为低延迟、低成本、开发简单，但面临能力瓶颈与逻辑复杂性限制。 Multi-Agent通过角色分工提升复杂任务（如代码审查、舆情监控）的准确性与扩展性，但通信成本高且需精细编排以避免死锁。 选型建议：优先优化Single-Agent；当任务涉及角色冲突、长链路或高可靠性需求时，再引入Multi-Agent。核心原则是“如无必要，勿增实体”。
2026-05-07 01:36:04
340
原创 一般Agent系统怎么做意图识别啊
本文探讨了Agent系统中意图识别从关键词匹配到语义路由的技术演进。介绍了5种主流方案：1)结构化输出(Pydantic/JSON Schema)适用于简单稳定场景；2)向量检索方案适合大规模意图分类；3)语义路由混合方案作为高效过滤层；4)层次化意图识别处理复杂任务。文章对比了各方案优缺点，指出结构化输出是生产环境首选，向量方案适合大规模场景，混合模型平衡性能与准确率。最后给出工程建议：在LangGraph架构中采用LLM+槽位校验机制，实现意图识别与信息补全的闭环流程。
2026-05-07 01:34:26
416
原创 mcp有什么缺点???
MCP协议的工业级应用困境 MCP协议作为AI工具调用标准，在广泛应用中暴露出显著缺陷： 安全风险突出：存在权限混淆代理、工具中毒和鉴权缺失等问题，易被恶意利用。 性能成本双高：上下文过载增加token消耗，网络延迟影响实时响应，暴力调用推高API成本。 工程维护复杂：架构沉重、调试困难、版本碎片化，小项目维护成本过高。 功能局限明显：无法替代知识库解决方案，状态同步困难影响扩展性。 应用建议： 个人工具开发：适用 企业级应用：必须增加权限隔离网关等安全措施 小项目：建议坚持传统Tool Calling方式
2026-05-06 23:14:07
42
原创 从复用性角度看，多次请求下 MCP 与 Function Calling 在 Agent 层面有何差异？
本文比较了Function Calling和MCP协议在AI代理开发中的复用性差异。Function Calling存在模型依赖性高、传输成本大等问题，每次请求都需要携带完整的函数定义，在多工具场景下会造成资源浪费。而MCP采用标准化协议和Client-Server架构，支持跨模型跨平台的工具复用，通过动态发现机制按需获取资源，显著降低了传输负担。MCP将工具实现逻辑下沉到服务端，实现业务解耦，使得能力更新可以自动同步到所有连接的代理。总体来说，Function Calling适合简单场景，而MCP更适用于
2026-05-06 22:52:50
135
原创 为什么mcp还需要Prompts??
摘要：MCP架构中Prompts（提示模板）的设计意义在于：(1)实现知识的"服务端化"，通过标准化的专家指令解决指令碎片化问题；(2)动态组合Resources和Tools，将复杂任务链路封装为简单操作；(3)引导AI发现更多任务可能。相比Tools（原子操作能力）和Resources（原始数据），Prompts提供的是业务逻辑标准和执行规范，使MCP Server从"驱动程序"升级为"智能工作站"。这种设计让AI不仅能执行基础操作，还能遵循预设
2026-05-06 22:46:15
142
原创 mcp的交互方式
如果你把太多文件都作为 Resource 塞给 AI，会导致上下文被无用信息填满。Resource 是对数据的抽象，它将外部数据（如文件、数据库、日志）转化为 AI 可以理解的 URI。在你的 Python 代码实现中，这三种能力分别通过不同的 JSON-RPC 方法（如。Prompts 是一组预设的指令模板，旨在降低复杂任务的交互门槛。这三种方式共同构建了 AI 与外部世界沟通的完整维度。正如你在小红书一面中提到的，MCP 的一大缺点是。这是最常用的交互方式，类似于你熟悉的。来平衡这三种交互方式。
2026-05-06 22:44:35
80
原创 什么是 MCP（模型上下文协议）？它解决了什么问题？
摘要： MCP（Model Context Protocol）是Anthropic提出的开放标准协议，旨在为AI模型与外部数据源/工具提供通用接口，类似"USB接口"实现即插即用。它解决三大核心问题：1）消除重复开发连接器的碎片化问题；2）规范上下文管理（Resources/Prompts/Tools三类交互）；3）解耦模型与工具，保障数据自主性。与Function Calling相比，MCP具有复用性强、支持复杂协议、基于网络通信等优势。但存在上下文污染、状态监控不足、安全隐患等局限。
2026-05-06 22:37:35
300
原创 Redis 和 Caffeine 构建的多级缓存，如何保持数据一致性？
摘要：分布式系统中采用Caffeine（L1本地缓存）与Redis（L2分布式缓存）的多级缓存架构，核心挑战在于数据一致性。解决方案包括：1）通过MQ广播通知各节点清除本地缓存；2）利用Binlog异构同步实现自动化清理；3）Redis Pub/Sub订阅机制。兜底策略涉及差异化TTL、本地消息表重试补偿及互斥锁双删策略。场景推荐：高并发场景选MQ广播+差异化TTL，低侵入需求用Binlog同步，强一致性业务需分布式锁+强制读库。组合方案“数据库更新+MQ异步失效+短TTL兜底”平衡性能与一致性，尤其适用于
2026-05-06 20:44:50
315
原创 synchronized 锁升级流程
本文分析了Java中synchronized锁升级机制的核心流程和优化原理。锁升级过程分为三个阶段：偏向锁通过记录线程ID实现单线程快速访问；轻量级锁通过CAS自旋处理短时竞争；重量级锁则在激烈竞争时使用操作系统级阻塞。现代JVM采用自适应策略动态调整自旋次数，而非固定阈值。这种分级机制有效平衡了性能与并发需求：偏向锁优化单线程场景，轻量级锁处理交替访问，重量级锁应对高并发竞争。该设计既避免了不必要的系统调用开销，又能在必要时保证线程安全，是Java高效并发的重要实现。
2026-05-06 11:37:10
160
原创 你描述一下轻量级锁
摘要： 轻量级锁是JVM针对synchronized的优化策略，通过CAS操作避免传统重量级锁的互斥量开销。其核心思想是假设多数场景下线程交替执行而无实质竞争，利用用户态的CAS修改对象头标记。执行流程包括分配锁记录空间、CAS抢锁及自适应自旋处理竞争。优点是无竞争时性能显著提升，缺点是竞争激烈时因自旋消耗可能劣于重量级锁，此时会升级为重量级锁。轻量级锁平衡了性能与资源消耗，成为synchronized高效处理交替执行场景的关键机制。（149字）
2026-05-06 11:35:39
229
原创 为什么ConcurrentHashMap的jdk8抛弃了ReentranceLock,选用了CAS+synchronized??
JDK 1.8的ConcurrentHashMap采用CAS+synchronized替代1.7的分段锁机制，实现了更精细的锁粒度优化。主要改进包括：1）锁粒度从Segment细化到桶级别，减少竞争；2）利用JVM对synchronized的优化（偏向锁、自旋等）降低开销；3）采用CAS优先策略，仅在冲突时使用synchronized；4）非公平锁特性减少上下文切换。相比1.7版本，1.8在内存占用、并发度和性能上都有显著提升，体现了"无锁优先，细锁兜底"的设计思想。
2026-05-06 11:01:33
628
原创 我不理解为什么说是非公平锁可以避免公平锁的线程休眠和恢复操作
摘要： 非公平锁通过允许新线程直接尝试获取锁，避免了公平锁模式下线程必须排队等待的昂贵开销。在理想情况下，新线程可以跳过休眠和恢复过程，减少内核态与用户态的切换，提升吞吐量。公平锁严格遵循FIFO，确保公平但性能较低；非公平锁优先尝试CAS抢锁，失败才排队，提高了锁的利用率，但可能导致线程饥饿。两者的核心差异在于线程切换频率和吞吐量表现。
2026-05-06 11:00:23
740
原创 介绍一下Redisson的看门狗机制
Redisson的看门狗机制通过自动续期解决分布式锁的过期时间难题：当未指定锁定时长时，默认30秒过期并每10秒检查续期，既防止业务未完成锁失效，又避免客户端宕机导致死锁。该机制后台异步执行，在保证锁安全的同时解耦业务耗时预估，但存在性能开销和主从架构下的锁丢失风险。看门狗巧妙平衡了锁可靠性与自动释放需求，是长耗时任务场景下的重要保障。
2026-05-03 22:26:48
1106
原创 aof缓冲区是用来干嘛?
Redis的AOF缓冲区是持久化机制中的关键组件，主要解决磁盘I/O效率与内存处理性能之间的矛盾。它通过批量缓存写命令再异步写入磁盘，既保证了性能又确保数据原子性。在AOF重写期间，缓冲区与重写缓冲区协同工作：AOF缓冲区维护旧日志的完整性，防止重写失败时数据丢失；重写缓冲区则收集增量数据，确保新文件包含最新操作。这种双重缓冲机制既优化了常规写入性能，又为重写过程提供了数据安全保障，是Redis持久化可靠性的重要保障。
2026-05-03 21:51:04
240
原创 为什么会出现缓存删除失败的情况
摘要： 分布式系统中“先更新数据库，后删除缓存”策略存在删除失败风险，主要原因包括：1）网络或Redis服务故障；2）程序崩溃或异常处理缺失；3）分布式事务或并发竞争问题。解决方案包括：异步重试机制（通过MQ持久化消息并重试删除）和Binlog监听（解耦业务代码，通过数据库日志触发删除）。最终一致性是核心目标，建议结合缓存TTL（设置随机抖动过期时间）兜底，即使删除失败，脏数据也能通过过期机制自动修正。
2026-05-03 11:34:21
407
原创 Redis的旁路缓存策略和先删除缓存后更新数据库,先更新数据库后删除缓存,这三种策略之间有什么关系??
本文分析了缓存与数据库一致性问题的三种策略关系：旁路缓存（Cache Aside）是顶层架构模式，而"先删缓存后更库"和"先更库后删缓存"是其具体实现方案。重点比较了两种写时序策略的并发风险："先删缓存"方案易产生永久脏数据，需通过延时双删修复；"先更库后删缓存"是推荐方案，虽存在理论不一致可能但概率极低。文章还解释了为何采用删除而非更新缓存，并建议结合消息队列或Canal实现最终一致性。最后提供了三种策略的对比总结表，帮助开发
2026-05-03 11:33:36
346
原创 zset是怎么通过skiplist和hashtable来快速获取指定排名范围内的成员的??
Redis通过增强跳表结构实现高效排名范围查询，核心在于引入**跨度(Span)**属性。在跳表每层指针中记录跨越的节点数，使得可以快速计算排名：1) 定位阶段($O(\log N)$)：通过累加Span值对数时间找到起始节点；2) 遍历阶段($O(M)$)：通过底层链表顺序获取后续节点。Dict仅用于成员分数映射，不参与排序操作。即使在rehash期间，SkipList仍保持有序结构，确保排名查询不受影响。这种"Span跳表+底层链表"的设计完美平衡了定位和遍历的效率需求。
2026-05-01 21:19:30
582
原创 zset为什么要用到skiplist+Dict的数据结构
Redis的有序集合(zset)巧妙结合了跳表(SkipList)和字典(Dict)两种数据结构，实现全方位高性能。跳表提供O(logN)的有序区间查询，字典实现O(1)的成员查找。两者通过指针共享避免内存浪费，字典还采用渐进式rehash保证扩容时的性能。这种"空间换时间"的设计思路，既满足了ZSCORE等命令的快速查询，又支持ZRANGE等范围操作，实现了1+1>2的效果，是大型数据库索引设计的经典范例。
2026-05-01 19:26:54
462
原创 怎么理解Redis的String的二进制安全??不再以\0作为判断标准
Redis 通过 SDS (Simple Dynamic String) 结构实现了二进制安全，与 C 语言传统字符串处理方式形成鲜明对比。C 语言以 \0 作为字符串结束标志，遇到二进制数据中的 \0 会提前截断；而 Redis 通过显式记录长度(len属性)来完整保存任意二进制数据，包括图片、序列化对象等。SDS 结构不仅避免了数据截断问题，还能 O(1) 时间复杂度获取长度，自动防止缓冲区溢出。这种设计使 Redis 字符串类型成为存储任意二进制数据的"万能内存胶布"，真正实现了&
2026-04-27 10:43:37
345
原创 RC确实是每次查询都生成读视图,但是都是快照读啊,和读已提交没半毛钱关系吧
摘要：文章解释了数据库隔离级别中"读已提交"（RC）与"快照读"的关系。关键点在于：1）RC级别的快照读每次查询都会重新生成快照，反映最新已提交数据；2）这与"可重复读"（RR）形成对比，RR的快照在事务期间保持不变；3）快照读是实现隔离级别的技术手段，RC通过频繁更新快照实现"读已提交"的语义；4）RC允许同一事务内多次查询看到其他事务已提交的修改（不可重复读），这符合其隔离级别定义。文章通过朋友圈刷新的比喻生动说明了不同隔离
2026-04-26 17:14:34
284
原创 隔离性和mvcc有什么关系吗
摘要： 隔离性是事务的ACID特性之一，MVCC是实现隔离性（特别是RC和RR级别）的核心技术。MVCC通过版本链和Read View机制，在RC级别每次生成新视图实现“读已提交”，在RR级别复用同一视图确保“可重复读”。它与锁机制协作，分别处理快照读和当前读，提升并发性能。MVCC无法直接支持RU和Serializable级别，前者无需版本控制，后者需严格串行化。隔离性定义需求，MVCC提供高效实现方案，二者是目标与手段的关系。分布式场景下（如Seata AT模式），需结合全局锁与本地MVCC协调多服务隔
2026-04-26 15:40:53
288
原创 为什么保证隔离性可以防止多个事务并发度写同一个数据的时候,导致数据不一致?
摘要： 隔离性通过排他锁（X锁）确保并发事务对数据的修改按顺序执行，防止"丢失更新"等数据不一致问题。其核心机制包括：1）事务修改数据前必须获取X锁，阻塞其他并发写操作；2）强制所有隔离级别在写操作时串行化处理；3）与原子性联动，确保事务提交前中间状态不可见。这种设计以降低写并发性为代价，换取数据的绝对一致性，但可能引发死锁。面试时可强调隔离性通过锁机制将并发写转为串行执行，从根本上杜绝脏写和更新丢失。
2026-04-26 15:31:57
237
原创 我的理解是当前读需要获取X锁,快照读不获取锁,所以读写不互斥,因此提高并发量是吧
MVCC（多版本并发控制）通过"读写分离"机制显著提升数据库并发性能。其核心原理是：读操作通过Undo Log访问历史版本数据（快照读），无需加锁；写操作获取X锁修改当前数据（当前读）。这种机制消除了读写互斥，使查询不会被更新操作阻塞，大幅降低锁竞争。虽然写-写操作仍需排队，但系统整体吞吐量得到质的提升。MVCC在保证事务隔离性的同时，实现了近乎无锁的高并发访问，让数据库从"单车道"变成"高架桥"式并行处理。
2026-04-26 11:36:46
318
原创 什么是mvcc,面试的时候怎么说
摘要： MVCC（多版本并发控制）通过维护数据的历史版本实现读写并发，核心机制包括： 隐藏字段（事务ID、回滚指针）标记数据版本； Undo Log形成版本链，保存修改前的数据； Read View基于事务ID判断数据可见性，决定读取哪个版本。 不同隔离级别下，MVCC行为不同：RC每次查询生成新Read View（可能不可重复读），RR复用同一Read View（保证可重复读）。MVCC虽能缓解幻读，但无法完全避免，需结合锁机制解决。面试需重点阐述可见性判断逻辑及版本链遍历过程。
2026-04-26 11:27:07
227
原创 我现在能理解mvcc让读不阻塞,但是无法理解mvcc让写不阻塞??
MySQL InnoDB 的 MVCC 机制只解决了"读-写"冲突，通过版本快照实现读操作不被写操作阻塞，但"写-写"冲突仍需通过行锁机制处理。常见的误解源于 MVCC 提升了写并发性，实质是写操作不再被读操作阻塞。在 UPDATE/DELETE 等当前读操作时，事务必须获取行排他锁，若冲突则等待。只有在分布式数据库或特定存储引擎中才可能实现写不阻塞。正确理解是 MVCC 实现了"读不被写阻塞"，而非"写不被写阻塞"。这一原理对
2026-04-26 11:26:00
367
原创 where id NOT IN(?，?,?) 会走索引吗?
MySQL优化器基于成本准则决定是否使用索引，核心在于计算回表成本与全表扫描成本。当NOT IN等条件过滤后数据量较少（如1%），优化器会选择索引+回表；若剩余数据量大（如90%），则选择全表扫描以避免大量随机I/O。关键因素是索引选择性：数据"少而精"走索引，"多而杂"则全表扫描。覆盖索引可消除回表开销，此时即使剩余数据多也会走索引。本质是数学计算，而非固定规则。
2026-04-25 23:46:52
243
原创 如果查询的两个表中一个是小表，一个是大表，IN适合于外表大而内表小的情况，EXISTS适合于外表小而内表大的情况。
数据库优化中，"小表驱动大表"是核心原则。对于IN查询，适合"外大内小"场景：先执行子查询（小表），结果存入内存，再遍历外表（大表）快速匹配。对于EXISTS查询，适合"外小内大"场景：先遍历小外表，每次通过索引快速查询大内表。IN查询优势在于小内表可完全缓存，EXISTS查询优势在于小外表减少查询次数。关键区别在于驱动顺序和索引利用，选择哪种方式取决于表的大小关系和索引情况。
2026-04-25 10:20:48
242
原创 Java8 为什么这里把key的hashcode取出来，然后把它右移16位，然后取异或?
HashMap的扰动函数(h = key.hashCode()) ^ (h >>> 16)是为了解决哈希冲突问题。当数组长度较小时，直接取哈希值的低位会导致高位信息丢失，造成严重碰撞。扰动函数通过将高16位与低16位异或运算，使高位特征"揉"入低位，让32位哈希值的所有信息都参与下标计算。案例显示，两个仅高位不同的哈希值，扰动前会碰撞，扰动后则被分流到不同下标，有效减少了冲突。这种设计充分利用了32位哈希值的全部信息，提升了哈希分布的均匀性。
2026-04-22 22:41:27
320
原创 ArrayDeque是基于什么样的核心痛点下诞生的??有什么核心优势
本文深度解析了Java中的ArrayDeque类，指出其作为双端队列首选方案的核心优势。相比老旧的Stack、ArrayList和LinkedList，ArrayDeque采用循环数组实现，具有两端O(1)操作、内存紧凑、缓存友好等优势，同时统一了队列和栈的API。但它不支持null元素、非线程安全且不适合随机访问。文章建议在需要高性能队列或栈时优先选择ArrayDeque。
2026-04-22 11:20:54
330
PHP写链表 页面刷新问题
2021-06-17
TA创建的收藏夹 TA关注的收藏夹
TA关注的人