- 博客(62)
- 收藏
- 关注
RSS订阅原创 通用：一文搞懂MQ：定义、产品、区别与SpringBoot实战
中小微企业 / 微服务解耦：首选 RabbitMQ，集成简单、运维成本低、可靠性高，能满足 80% 的业务场景；高吞吐场景（日志 / 大数据）：首选 Kafka，单机十万级吞吐量，支持海量数据存储，适合日志收集、实时计算；电商核心交易 / 分布式事务：首选 RocketMQ，原生支持事务消息、延迟消息，高可用设计更适合金融级场景；传统项目迁移 / 老系统兼容：可选 ActiveMQ，支持 JMS 规范，能兼容老系统的消息格式，不建议新项目使用。MQ 作为微服务架构的“通信中枢”
2025-12-13 18:27:50
715
原创 Java 8 新特性全解析：从语法糖到编程范式的革新
Java 8 是 Java 发展史上的重要里程碑，引入了 Lambda 表达式、函数式接口、Stream API 和方法引用等核心特性，显著提升了开发效率和代码可读性。Lambda 表达式简化了匿名内部类写法，函数式接口为 Lambda 提供类型支持，Stream API 实现了声明式集合处理，方法引用进一步精简代码。这些特性共同推动了 Java 向函数式编程演进，使开发者能够编写更简洁、高效的代码，同时支持并行处理提升性能。
2025-10-31 16:58:54
726
原创 MyBatis 源码深度解析：从 Spring Boot 实战到底层原理
本文深入解析MyBatis框架，从Spring Boot集成实践到核心源码分析。首先介绍MyBatis与Spring Boot的整合方式，包括依赖配置、实体类定义、Mapper接口编写及XML映射文件配置。重点剖析MyBatis的核心特性：动态SQL、结果映射、两级缓存机制和插件体系。最后解析MyBatis的执行流程，包括SqlSession获取、SQL解析执行及结果处理等核心环节，揭示其"接口层-核心处理层-基础支撑层"的三层架构设计。全文帮助开发者深入理解MyBatis的工作原理，提
2025-10-31 09:07:37
1165
1
原创 面试题：JVM面试问题口语化回答（含核心重点）
JVM是运行Java字节码的虚拟进程，实现"一次编译，到处运行"的核心功能。其内存模型包括线程私有的程序计数器、虚拟机栈、本地方法栈，以及线程共享的堆和方法区。对象主要在堆上分配，栈仅用于临时对象。JVM通过垃圾回收机制自动管理内存，使用可达性分析判断对象存活，并支持强、软、弱、虚四种引用类型。性能调优需关注吞吐量、延迟和GC指标，可使用jmap、jstack等工具诊断问题。类加载过程包含加载、验证等5个步骤，采用双亲委派机制的类加载器体系确保类加载安全。
2025-10-29 07:18:29
856
原创 Java IO与NIO详解：从基础到实战，一文搞懂两种IO模型
Java IO与NIO核心差异及选型指南 摘要：本文深入解析Java中BIO与NIO的核心差异与应用场景。BIO采用阻塞式IO模型，面向流操作，简单直观但高并发性能差；NIO通过Buffer、Channel和Selector三大组件实现非阻塞IO，单线程可处理多连接，特别适合高并发场景。文章通过代码示例对比两种模型，指出BIO适合连接数少且固定的场景，而NIO在聊天服务器、API网关等高并发系统中优势明显。开发者应根据实际业务需求选择IO模型，平衡开发效率与系统性能。
2025-10-28 06:19:30
984
原创 Dubbo源码深度剖析：从Spring Cloud集成到核心原理
/ 公共接口模块：api// 数据传输对象@Data// 权重参数名// 默认权重@Override// 校验参数// 只有一个提供者时直接返回// 抽象方法，由子类实现具体选择逻辑// 子类需实现的核心选择逻辑// 计算服务提供者的权重（考虑预热机制）// 启动时间（用于预热，刚启动的服务权重逐渐增加）if (uptime < WARM_UP_TIMEOUT) { // 预热时间内（默认10分钟）// 权重随启动时间线性增长（避免刚启动就接收大量请求）
2025-10-23 12:38:28
965
原创 ArrayList源码深度剖析：从底层原理到工作实战
ArrayList作为基于动态数组的集合实现，其核心优势在于随机访问效率高，适合读多写少、尾部操作多的场景。底层通过Object[]存储元素，size记录实际元素数量初始化方式影响后续扩容次数，已知元素数量时应指定初始容量扩容机制为1.5倍增长，触发时会复制数组（耗时操作）中间插入/删除需要移动元素，效率较低▲如有纰漏，烦请指正~~
2025-10-23 10:14:39
328
原创 设计模式-装饰器模式：从咖啡加配料看功能的动态扩展
装饰器模式摘要（147字）： 装饰器模式通过动态包装扩展对象功能，避免继承导致的类爆炸问题。以咖啡馆系统为例，基础咖啡类作为被装饰对象，配料（牛奶/糖）作为装饰器层层包装，每层装饰可添加新功能而不修改原有代码。该模式包含抽象组件、具体组件、抽象装饰器和具体装饰器四个角色，通过组合替代继承，完美支持功能的灵活扩展与自由组合。当需要为对象动态添加可选功能时，装饰器模式是优雅的解决方案。
2025-10-23 09:24:36
815
原创 设计模式- 模板方法模式：从制鞋流程看固定骨架与可变步骤的设计智慧
模板方法模式通过抽象类定义算法骨架，子类实现可变细节，实现代码复用与流程标准化。以鞋厂生产为例，抽象类ShoeProducer固定了"准备材料→裁剪→缝制→定型→质检"的流程（模板方法），子类只需实现材料、缝制等差异化步骤。该模式避免了代码重复，确保流程一致性，同时通过钩子方法（如needShape()）支持灵活调整。适用于存在固定流程但细节多变的场景，如支付处理、文档生成等。
2025-10-23 09:22:35
899
原创 设计模式-责任链模式：从鞋厂审批流程看请求处理的艺术
代理模式是一种结构型设计模式，通过在原始对象和客户端之间引入代理对象，实现对原始对象的间接访问和控制。本文以鞋厂销售场景为例，阐述了代理模式的核心思想：静态代理通过显式创建代理类（如经销商）为特定对象添加功能（会员验证、日志记录）；动态代理则利用反射机制（如JDK动态代理）在运行时自动生成代理，实现对多个对象的统一增强（权限校验、电子发票）。代理模式的典型应用包括权限控制、延迟加载、远程调用等场景，其核心优势在于不修改原始对象的情况下扩展功能，实现职责分离和访问控制。
2025-10-22 16:34:57
904
原创 设计模式-策略模式：从鞋厂促销活动看算法的灵活切换
本文以鞋厂促销活动为例，介绍策略模式的应用。策略模式通过将不同算法封装为独立策略类，实现算法的动态切换，解决传统if-else实现方式存在的耦合度高、可读性差、扩展性差等问题。文章详细展示了策略模式的四个核心角色（抽象策略、具体策略、环境类和客户端），并通过代码示例演示了如何实现满减、打折、积分等灵活促销策略。策略模式使系统能够根据不同场景动态切换算法，且新增策略时无需修改原有代码，极大提升了系统的可维护性和扩展性。
2025-10-22 15:54:52
755
原创 设计模式-代理模式：从鞋厂经销商看“中间商”的设计智慧
代理模式是一种结构型设计模式，通过在原始对象和客户端之间引入代理对象，实现对原始对象的间接访问和控制。本文以鞋厂销售场景为例，阐述了代理模式的核心思想：静态代理通过显式创建代理类（如经销商）为特定对象添加功能（会员验证、日志记录）；动态代理则利用反射机制（如JDK动态代理）在运行时自动生成代理，实现对多个对象的统一增强（权限校验、电子发票）。代理模式的典型应用包括权限控制、延迟加载、远程调用等场景，其核心优势在于不修改原始对象的情况下扩展功能，实现职责分离和访问控制。
2025-10-22 01:10:08
801
原创 设计模式-工厂模式：解耦对象创建的设计艺术
工厂模式：解耦对象创建的设计艺术 工厂模式通过封装对象创建逻辑，实现了创建与使用的分离，使代码更灵活、更易维护。它包含三种核心形态： 简单工厂：单一工厂类统一创建所有对象，适合产品种类少的场景。 工厂方法：每个产品对应专属工厂，通过继承扩展新产品，符合开闭原则。 抽象工厂：创建一系列相关产品族，支持多维度扩展。 工厂模式解决了直接创建对象导致的耦合度高、扩展性差等问题，将对象创建职责从业务代码中抽离，使系统更易维护和扩展。
2025-10-21 22:19:50
653
原创 设计模式-单例模式：从原理到实战的三种经典实现
单例模式是一种确保类仅有一个实例并提供全局访问点的设计模式，适用于配置管理、日志系统等场景。主要有三种经典实现方式： 饿汉式：类加载时即初始化实例，线程安全但可能浪费资源 懒汉式：首次调用时初始化，需同步机制保证线程安全，性能较差 双重检查锁（DCL）：结合两次判空和volatile关键字，兼顾性能与安全，是工业级常用方案 每种实现各有优劣，选择需根据具体场景考虑资源占用、并发需求和性能要求。日志管理器等典型应用通常采用DCL实现，确保高并发下的安全性和效率。
2025-10-21 20:41:33
1102
原创 Kafka零拷贝原理深度解析：从传统拷贝痛点到工作实践优化
Kafka的零拷贝技术，本质是利用操作系统内核的能力，规避用户态与内核态之间的无效数据拷贝，将CPU资源从“数据搬运”解放到“业务计算”上。其核心价值在高吞吐、大流量的工作场景中尤为突出——它不仅能降低CPU和内存带宽消耗，还能减少延迟，让Kafka支撑起百万级QPS的消息传输。▲如有纰漏，烦请指正~~
2025-10-18 17:49:28
739
原创 Java并发工具类详解：Semaphore、CyclicBarrier与CountDownLatch
Semaphore是"门卫"，通过许可机制控制同时访问资源的线程数，适合限流场景（如连接池、接口并发控制）。是"集合点"，让多个线程到达屏障后一起执行下一阶段，适合多步骤协同任务（如分阶段开发流程）。是"发令枪"，等待所有前置任务完成后触发后续操作，适合初始化、结果汇总等场景。这三个工具类均基于AQS（AbstractQueuedSynchronizer）实现，但设计目标不同。实际开发中需根据具体同步需求选择：如需控制并发量用Semaphore，如需多线程协同用，如需等待前置任务用。
2025-10-17 21:56:51
884
原创 SpringCloud-Sentinel实战与源码分析：从流量防护到底层实现
Sentinel的设计理念是“流量即资源”，将所有需要保护的对象（如接口、方法、服务）定义为“资源”，通过配置规则对资源进行流量控制。相比传统的熔断组件（如Hystrix），Sentinel具有更丰富的特性和更轻量的设计。"highestSystemLoad": 3.0, // 系统负载阈值（仅Linux有效）"avgRt": 1000, // 所有请求的平均响应时间阈值（毫秒）"maxThread": 200, // 系统总线程数阈值"qps": 1000, // 系统总QPS阈值。
2025-10-17 11:20:26
1047
原创 SpringCloud-Gateway实战使用与深度源码分析
SpringCloud-Gateway是Spring官方推出的第二代网关产品，基于Spring WebFlux构建，采用非阻塞异步模型，相比第一代的Zuul（1.x）性能更优，已成为微服务架构中网关的首选方案。// 优先级：值越小越先执行 } }});// 优先级：值越小越先执行 } }});// 优先级：值越小越先执行 } }
2025-10-16 20:27:22
402
原创 Nacos配置中心：SpringCloud集成实践与源码深度解析
Nacos配置中心作为SpringCloud生态中的核心组件，不仅解决了微服务配置管理的痛点（动态刷新、隔离、高可用），还具备易用性强、兼容性好、安全可靠等优点，是生产环境的首选。▲如有纰漏，烦请指正~~
2025-10-15 21:32:36
1830
1
原创 Nacos 2.x 深度解析：从 HTTP 到 gRPC 的跨越式升级，揭秘核心特性与实战配置
Nacos 2.x 通过引入 gRPC 协议，实现了从“能用”到“好用”的跨越式升级，在延迟、吞吐量、实时性等关键指标上均有质的提升。对于开发者而言，理解 2.x 的协议升级（HTTP → gRPC）、掌握核心配置（gRPC 端口、集群参数）、熟悉源码实现（服务注册的 gRPC 交互、配置的双向流推送），是在生产环境中充分发挥其性能优势的关键。随着微服务架构的规模化，Nacos 2.x 提供的高可用、高性能特性将成为支撑业务增长的核心能力。
2025-10-15 20:59:27
2019
原创 Spring Cloud 微服务架构实战：从核心组件到工作落地全解析
/ name：目标服务名（必须与 user-service 的 spring.application.name 一致）// fallback：熔断降级类（当 user-service 不可用时，调用 UserFeignFallback 的方法）// 接口路径、请求方式、参数需与 user-service 的接口完全一致// SentinelResource：标记该方法需要熔断限流（value 为资源名，自定义）// 熔断降级实现类（需注入 Spring 容器）@Component。
2025-10-14 16:20:30
385
原创 SpringBoot：自动装配机制
自定义Bean覆盖：若你在配置类中定义了和自动配置类同名的Bean（如），Spring会优先使用你的Bean，自动配置的Bean会失效（因配置文件覆盖：通过修改自动配置类的属性（如，覆盖默认的localhost）；排除不需要的自动配置类：通过，排除不需要的自动配置（如项目不用数据库，排除数据源配置）。在配置类中自定义了Bean后，发现无法注入，报。SpringBoot自动装配的本质，是“约定优于配置+条件筛选+可扩展。
2025-10-14 16:20:13
1148
原创 面试题：JVM
但有了双亲委派，会先委托给启动类加载器，启动类加载器已经加载过JDK的String类了，就不会再加载自定义的，防止恶意类冒充核心类；，这是最大的一块，所有对象都在这分配内存，分新生代（Eden、Survivor0/1）和老年代，GC主要就是回收堆里的垃圾，堆要是满了就会OOM，是内存管理的核心；上，但有个例外——“逃逸分析”优化后，要是对象没逃出方法（比如方法里new的对象只在方法内用，没返回出去），会被“标量替换”，直接存在栈上，这样能减少GC压力。
2025-10-14 16:19:49
690
原创 通用：JVM垃圾回收机制
分区适配生命周期：短期对象多就增大新生代（Eden/Survivor），长期对象多就增大Old区，避免对象“错配”导致GC频繁；算法匹配业务目标：延迟敏感（如用户接口）选CMS/G1，吞吐量优先（如后台任务）选Parallel Scavenge+Parallel Old，不盲目追求“最新收集器”；配置结合监控调优：线上必须开启GC日志，用jstatjmap/MAT等工具监控GC状态，根据实际问题调整配置，而非“照搬模板”。在 JVM 的内存模型中，程序计数器是唯一一个不会出现OOM报错的区域。
2025-10-13 15:56:31
1048
原创 通用：JVM内存模型
在Java开发中，“OOM（内存溢出）”“Full GC频繁”是线上故障中高频出现的问题，而这些问题的根源往往与JVM内存模型设计、垃圾回收（GC）机制密切相关。理解JVM内存布局的细节、掌握垃圾回收的核心逻辑，不仅能帮我们快速定位线上问题，更能通过合理配置优化系统性能。本文将从“内存模型拆解”“垃圾回收机制”“工作实战配置”三个维度，结合实际开发场景，吃透JVM的核心知识。
2025-10-13 15:56:11
1179
原创 通用：JVM-Java虚拟机基础知识
JVM是Java生态的基石，从Class文件的加载到运行时内存的管理，每一个环节都设计得非常严谨。当然，JVM的知识远不止这些，比如垃圾回收机制、JIT编译优化等，都是进阶学习的重点。▲如有纰漏，烦请指正~~
2025-10-13 15:55:48
846
原创 通用：Kafka 从入门到实战：Docker 部署与 Spring Boot 集成
在分布式系统中，消息中间件是实现服务解耦、异步通信的核心组件，而 Kafka 凭借其高吞吐、高可靠、可扩展的特性，成为日志收集、流式处理、消息队列等场景的首选方案。
2025-10-10 13:46:13
1229
原创 面试题：（MySQL）
简单说，回表就是查两次数据首先，InnoDB里有聚簇索引（主键索引），叶子节点存的是整行数据；非聚簇索引（比如普通索引）叶子节点存的是主键值，不是整行数据；所以当你用非聚簇索引查数据时，比如用name索引查select * from user where name='张三'，第一步先查name索引，拿到主键id，第二步再用id查聚簇索引，拿到整行数据——这第二步就是回表；总结：回表只发生在非聚簇索引（普通索引、联合索引等）中，聚簇索引查一次就够，不用回表。
2025-10-10 13:45:56
577
原创 通用：Kafka架构组件和特性
Kafka 作为分布式消息中间件的标杆，其架构设计与特性优化需围绕“业务场景”展开——高吞吐场景优先调优批量与压缩，高可靠场景强化副本与确认机制，低延迟场景减少等待与缓存。组件认知：理解 Partition 是并行性的核心、Replica 是可靠性的保障、KRaft 是未来元数据管理的趋势，避免因基础概念模糊导致架构设计失误；配置取舍：没有“万能配置”，需在吞吐/延迟/可靠性之间平衡（如acks=all提升可靠性但降低吞吐，降低延迟但增加 IO）；运维监控。
2025-10-10 13:45:34
727
原创 通用：MySQL之BinLog与RedoLog二阶段提交机制
性能问题：两个日志的写入机制不同（RedoLog 是循环写，BinLog 是追加写），强制同时写入会导致 IO 阻塞，降低并发性能；实现复杂度：InnoDB 是第三方存储引擎（后被 MySQL 收购），与服务器层（负责 BinLog）属于不同模块，"一阶段"需要强耦合两者的写入逻辑，难以维护。二阶段提交通过"松耦合"的方式协调两个模块，既保证了一致性，又保留了各自的独立性。：通过二阶段提交保证事务一致性，RedoLog 保障本地持久性，BinLog 保障主从同步与恢复。
2025-10-09 12:03:40
904
原创 通用：MySQL-主从同步之BinaryLog
线程所在节点核心职责常见问题排查点Dump线程主库推送BinaryLog给从库，维护主从连接主库看是否有“Binlog Dump”线程IO线程从库接收BinaryLog，写入中继日志从库看是否为YesSQL线程从库解析中继日志，执行SQL变更从库看是否为Yes。
2025-10-09 12:03:25
1185
原创 通用：MySQL主库BinaryLog样例解析（ROW格式）
在生产环境中，BinaryLog以二进制形式存储，无法直接查看，需通过MySQL自带的工具解析为可读文本。以下基于前文配置的主库（），提供，涵盖“表结构变更（DDL）”和“数据行变更（DML）”两种核心场景，并标注关键字段含义。
2025-10-09 12:02:55
890
原创 通用：MySQL-LBCC并发锁机制
LBCC的核心思想是“谁先操作数据，谁就持有数据的锁，其他事务需等待锁释放后才能操作”，通过“排他性锁定”避免并发事务对数据的“交叉修改”，确保事务执行过程中数据的“可见性”和“一致性”。死锁（Deadlock）是指两个或多个事务互相持有对方所需的锁资源，且均不主动释放，形成 “循环等待” 的僵局。例如：事务 A 持有锁 1、等待锁 2，事务 B 持有锁 2、等待锁 1，两者无法推进，最终触发 InnoDB 的死锁检测机制，回滚其中一个事务以打破僵局。
2025-10-08 17:43:20
1180
原创 通用：MySQL-InnoDB事务及ACID特性
在讲解ACID前，需先明确事务的核心定义与业务价值——理解“事务解决了什么问题”，才能更深入地掌握其实现原理。事务（）是数据库中“一组不可分割的SQL操作序列”，这组操作要么全部执行成功（COMMIT），要么全部执行失败（ROLLBACK），不会出现“部分成功、部分失败”的中间状态。典型业务场景示例（电商下单）插入订单记录（INSERT INTO orders …）；扣减商品库存（UPDATE products SET stock = stock-1 WHERE product_id=…）；
2025-10-08 16:05:46
904
原创 通用：MySQL-InnoDB慢查询及优化
在优化慢查询前，需先明确MySQL对“慢查询”的定义——执行时间超过“阈值”的SQL语句，这个阈值由MySQL的配置参数控制，默认值并非适用于所有业务场景。索引优先，避免盲目调参：绝大多数慢查询的根源是“无索引”或“索引失效”，优先通过索引优化（如覆盖索引、联合索引）解决，参数调优仅作为补充；结合InnoDB特性：充分利用InnoDB的缓存池、B+树索引、事务日志等特性，避免“脱离存储引擎谈优化”（如SSD硬盘关闭平衡性能与安全性：如。
2025-10-08 14:51:30
760
原创 通用：MySQL-InnoDB如何解决幻读问题——间隙锁
理解锁定范围是关键：Next-Key Lock的锁定范围遵循“左开右闭区间”，需根据“索引类型（唯一/非唯一）”和“数据存在性”判断最终锁定范围；唯一索引优先：唯一索引的等值查询会让间隙锁退化，减少锁竞争，是高并发场景的首选；隔离级别适配核心业务（需防幻读）：使用级别，依赖Next-Key Lock保障一致性；高并发非核心业务（可接受不可重复读）：使用级别，关闭间隙锁提升性能；避免大范围锁定：尽量避免对“不存在的索引值”或“超大范围”执行加锁查询，减少锁等待与死锁风险。
2025-10-08 14:51:12
892
原创 通用：MySQL-InnoDB-count&limit&order优化
索引优先order by必须建索引，单字段排序用“单列索引”，多条件排序用“联合索引”；顺序匹配：联合索引需遵循“WHERE 字段在前，排序字段在后”，排序方向与索引方向一致；覆盖为王：索引需包含所有查询字段（避免回表），减少优化器放弃索引的概率；控制数据量：先过滤再排序，限制最大分页条数，避免对超大量数据排序；版本利用：MySQL 8.0+ 优先用“降序索引”“隐藏索引”，提升优化效率与安全性。▲如有纰漏，烦请指正~~
2025-10-07 17:13:50
778
原创 通用：MySQL执行计划explain深度解析：从字段含义到工作实战优化
先看type，再看Extratype决定查询的“基础性能等级”（避免ALL/index），Extra排查“隐性性能损耗”（优先解决Using temporary/Using filesort）；索引有效性是关键：通过与key的对比，判断索引是否生效；通过key_len判断联合索引是否被完全利用；结合实际场景优化：不要盲目追求“最优执行计划”（如为了type=ref而建大量索引），需平衡“查询性能”与“写性能”（索引过多会导致INSERT/UPDATE/DELETE变慢）；善用进阶工具。
2025-10-07 15:47:27
1002
原创 通用-MySQL- InnoDB索引深度解析
从二叉树到B+树的演进，解决了“深度过深”“I/O效率低”“范围查询差”等问题；聚簇索引与二级索引的配合，兼顾了“主键查询效率”和“非主键查询灵活性”；实际工作中，索引优化的核心是“平衡”——既不能为追求查询速度创建过多索引（影响写入），也不能为简化维护放弃必要索引（影响查询）。记住：最好的索引不是“越多越好”，而是“刚好满足需求”。掌握B+树原理，善用EXPLAIN分析，结合业务场景设计索引，才能让MySQL在高并发场景下保持高效运行。
2025-10-07 13:45:34
985
原创 通用：MySQL-Redo log和Undo log原理
Redo Log（重做日志）是InnoDB实现事务持久性（ACID中的D）的核心机制，本质是一份"物理日志"——记录的是数据页的修改动作（如“将表user的第100号数据页中，偏移量500的位置值从100更新为200”），而非SQL语句本身。崩溃恢复：系统崩溃后，未写入磁盘的数据页可通过Redo Log重新执行修改操作，恢复已提交事务的数据；减少磁盘I/O：事务执行时，只需将修改记录到Redo Log（顺序写入），无需立即刷写数据页（随机写入），大幅降低磁盘I/O开销。
2025-10-06 14:48:46
2140
空空如也
空空如也
TA创建的收藏夹 TA关注的收藏夹
TA关注的人