- 博客(296)
- 资源 (9)
- 收藏
- 关注
RSS订阅
原创 想查看微信好友撤回的消息？Python帮你搞定
要说微信最让人恶心的发明，消息撤回绝对能上榜。比如你现在正和女朋友用微信聊着天，或者跟自己喜欢的女孩子聊着天，一个不留神，你没注意到对方发的消息就被她及时撤回了，这时你很好奇，好奇她到底发了什么？于是你打算问问她发了什么，结果她回一句"没什么"。这一回复，让你的好奇心更加强烈了，顿时就感觉消息撤回这一功能就是用来折磨人的。那么有没有什么办法能够知道你心爱的她(他)到底撤回了什么呢？不要着急，P...
2019-12-01 13:50:59
95640
203
原创 20行Python代码爬取王者荣耀全英雄皮肤
引言王者荣耀大家都玩过吧，没玩过的也应该听说过，作为时下最火的手机MOBA游戏，咳咳，好像跑题了。我们今天的重点是爬取王者荣耀所有英雄的所有皮肤，而且仅仅使用20行Python代码即可完成。准备工作爬取皮肤本身并不难，难点在于分析，我们首先得得到皮肤图片的url地址，话不多说，我们马上来到王者荣耀的官网：我们点击英雄资料，然后随意地选择一位英雄，接着F12打开调试台，找到英雄原皮肤的图片...
2019-11-21 22:01:03
239836
253
原创 从入门到精通，Java学习路线导航
引言最近也有很多人来向我"请教"，他们大都是一些刚入门的新手，还不了解这个行业，也不知道从何学起，开始的时候非常迷茫，实在是每天回复很多人也很麻烦，所以在这里统一作个回复吧。Java学习路线当然，这里我只是说Java学习路线，因为自己就是学Java的，对Java理当很熟悉，对于其它方面，我也不是很了解。基础阶段首先是基础阶段，在基础阶段，我们必须掌握Java基础，Mysql数据库，Ora...
2019-11-12 19:34:42
161952
832
原创 SpringBoot 服务注册与发现：Nacos/Consul/Eureka
很多开发者只会简单集成依赖、启动服务，却不懂 CAP 适配原理、健康检查机制、集群容错逻辑、负载均衡底层，遇到线上服务注册异常、实例误剔除、调用报错、负载不均问题就无从排查。，是所有微服务通信的基础。持续更新 SpringBoot、微服务、分布式架构、中间件实战、面试干货，帮你夯实技术基底，突破职场技术瓶颈。：客户端主动心跳上报，15秒一次，超时90秒剔除实例，自带自我保护机制，容错性极高，适合不稳定网络环境。：微服务启动时，自动将自身 IP、端口、服务名、健康状态注册到注册中心，集群环境同步至所有节点。
2026-05-28 09:00:00
395
原创 SpringBoot 消费者并发控制：线程池配置
MQ消费者并发调优，看似是简单的参数配置，实则是高并发系统稳定性的核心基石。后续我会持续更新SpringBoot MQ幂等性、死信队列、延迟消息、消息可靠性、集群高可用等全套生产实战干货，帮你从零搭建稳定的分布式消息架构。慢消费业务预取过多消息，会导致客户端本地堆积大量未消费消息，重启服务后重复消费，引发数据错乱。默认线程池无上限、无命名、无拒绝策略，流量峰值会无限创建线程，最终导致内存溢出、服务宕机。
2026-05-27 09:00:00
684
原创 SpringBoot 广播消息实现（发布/订阅）
持续更新 SpringBoot、微服务、MQ 中间件、架构实战、面试刷题干货，帮你夯实技术底盘，轻松搞定工作与面试。生产者发送一条消息到 Fanout 交换机，所有绑定该交换机的队列，都会完整收到这条消息。广播场景多为重要通知、缓存同步，自动ACK会导致业务未执行完成消息丢失。不管路由键是什么、不管队列名称，只要完成绑定，就会无条件广播投递。缓存刷新、配置更新、全局通知、多节点日志同步、服务状态广播。
2026-05-26 09:00:00
295
原创 SpringBoot 消息幂等性设计：防重复消费
很多线上脏数据、资金问题、业务异常，根源都不是业务 Bug，而是忽略了 MQ 重复消费的特性。消费者业务执行成功，但返回 ACK 确认时网络抖动、超时，MQ 未收到确认，判定消费失败，重新投递消息。持续分享 Java、SpringBoot、MQ、微服务、架构设计、面试干货，帮你夯实技术底层，搞定面试与线上问题。针对不同业务场景、不同并发量级，整理业界通用 4 套方案，从轻量到厚重，从通用到专用，按需选用。业务执行一半、执行成功后程序宕机、重启，未完成 ACK，触发 MQ 重试。
2026-05-25 09:00:00
578
原创 对象初始化过程深度解析
方法机制，到单类、父子类完整初始化流程，从变量四层赋值规则，到面试高频陷阱、避坑技巧，覆盖了入门、进阶、面试的全部核心考点。本文持续更新 Java 核心基础、JVM 底层原理、面试高频考点、实战避坑技巧，干货满满，无废话、纯硬核技术输出！为什么父类构造方法中调用子类重写的方法，获取的子类成员变量永远是默认值？父类 private 对子类不可见，子类同名方法是全新方法，不是重写。父静态 → 子静态 → 父实例 → 父构造 → 子实例 → 子构造。• final、static、继承、多态混合时的诡异现象？
2026-05-24 09:00:00
546
原创 方法重载与重写的区别与陷阱
重载和重写看似简单，却是 Java 面向对象、多态机制的基石，也是面试和实际开发的高频考点。把重载当成重写、静态方法误判重写、协变返回混淆、参数匹配出错、多态调用失效。：静态方法属于类，不属于对象，编译期绑定父类类型，和子类无关，不存在多态。重载：同类、同名不同参、编译绑定、静态多态，为了灵活适配多场景调用。2. 杜绝参数写错、返回值错误、静态覆盖、权限错误等所有重写问题。重写：父子、同名同参、运行绑定、动态多态，为了子类个性化扩展。返回值、访问权限、方法异常、方法修饰符，完全不参与重载判断！
2026-05-23 09:00:00
618
原创 SpringBoot 延迟消息实现（RabbitMQ 延迟交换）
核心逻辑：消息先进入普通队列，设置过期时间（TTL），消息过期后无人消费，自动变为死信，被转发到死信队列，消费者监听死信队列实现延迟消费。，所有消息都是立即投递、立即消费，没有内置定时延迟投递机制。想要实现延迟效果，只能通过曲线方案实现。• 超大延迟（超过3天）不建议使用，RabbitMQ重启会丢失未执行延迟消息。• 延迟消息不适合超高精准定时任务，毫秒级误差可忽略，秒级完全精准。：前面长延迟消息未过期，后面短延迟消息会被卡住，延迟严重不准。，禁止自动ACK，防止消息丢失、业务未执行但消息已删除。
2026-05-22 17:30:00
658
原创 Scanner类的正确用法
但绝大多数初学者只停留在“能用就行”的阶段，经常遇到：输入跳行、读取为空、报错崩溃、资源泄漏、输入非法数据程序闪退等各种问题。3. 基本类型读取方法（nextInt等）会残留换行，导致nextLine空读跳行，必须手动吸收换行。1. Scanner 是Java控制台标准输入工具，属于IO资源，用完必须关闭。，带你从零吃透Java基础，告别模糊知识点，轻松搞定作业、考试和面试！彻底杜绝跳行问题，所有输入统一按行读取，再手动转换类型。• hasNextInt()：判断下一个输入是否为整数。
2026-05-22 09:00:00
658
原创 Java模块化基础：module-info.java
传统 Java 中，只要知道某个类的全限定名，就能通过反射或直接引用访问该类，哪怕这个类是某个模块的内部实现（如DAO层、工具类内部），容易导致代码耦合、不安全，且维护困难。：传统 Java 中，只要知道某个类的全限定名，就能通过反射或直接引用访问该类，哪怕这个类是某个模块的内部实现（如DAO层、工具类内部），容易导致代码耦合、不安全，且维护困难。：大型项目中，代码量庞大、依赖关系复杂，没有明确的模块边界，开发者难以理清“哪个模块依赖哪个模块”“哪些代码可以被外部访问”，导致开发效率低、交接成本高。
2026-05-21 17:30:00
733
原创 var局部变量类型推断的利弊
编译后，var会被替换为具体的类型，与显式声明类型的代码完全一致，既保证了类型安全，又不影响程序运行效率。当变量的初始化表达式无法直接看出类型，或者变量名不够清晰时，var会让阅读者无法快速判断变量的类型，必须依赖IDE提示或跳转查看方法返回值，大幅增加阅读成本，尤其在多人协作项目中，这种问题会更加突出。同时，阅读者也无法快速判断变量的类型。好的代码，变量名本身就应该具备“自解释性”——通过变量名就能知道变量的用途和类型，此时显式声明类型反而会成为“冗余信息”，var能让阅读者更聚焦于变量的含义。
2026-05-21 09:00:00
1140
原创 文本块（Text Blocks）处理多行字符串
无论是编写复杂的SQL查询语句、格式化的JSON字符串、HTML邮件模板，还是多行日志、接口说明，传统方式都需要手动拼接字符串、添加换行符、转义特殊字符，不仅代码冗长杂乱，还极易出现语法错误，后期维护更是举步维艰。始终保持「起始标记、结束标记缩进一致」，且与代码块的缩进对齐（如在方法内部，与方法体的缩进保持一致），这样能最大程度保证文本块的格式整洁，避免出现不必要的缩进混乱。对于复杂的接口说明、方法注释，文本块可保留换行和格式，比传统的多行注释（/* */）更灵活，也可用于生成接口文档的描述信息。
2026-05-20 17:30:00
617
原创 switch表达式：从Java 12到Java 17的演进
从Java 1.0诞生之初的传统switch，到Java 12的预览性革命，再到Java 14的正式落地，最终在Java 17实现模式匹配的封神升级，每一个版本的迭代都精准解决了开发者的核心痛点，也重构了Java开发者对“分支判断”的编写习惯。switch表达式的升级，看似是简单的语法优化，实则体现了Java官方“简化开发、提升安全性”的核心思路——从Java 12到Java 17，5年时间的迭代，让一个笨重的传统语句，变成了优雅、高效、安全的表达式，也成为了面试中的高频考点。模式匹配的实现原理是什么？
2026-05-20 09:00:00
544
原创 类型转换：隐式、显式与类型提升
底层原因：CPU的原生运算单元主要支持 int、long、double 类型，对 byte、short、char 类型的运算效率极低，因此JVM会自动将这些小类型提升为 int 或更高类型，再进行运算。底层原理：JVM会自动拓宽数据的存储宽度（比如byte的1字节拓宽为short的2字节），补充高位符号位（正数补0，负数补1），保证数据的原值不变，因此不会发生精度丢失或溢出。类型转换的所有规则，本质都是围绕「精度（取值范围）」展开——小范围类型可以安全转为大范围类型，大范围转小范围则存在风险。
2026-05-19 09:00:00
561
原创 Java编译期常量与运行时常量
这是编译期常量最核心的特性，也是面试高频考点—— 因为编译期常量的值已经嵌入到调用类的字节码中，访问时无需加载其所在的类，因此不会触发类的初始化（不会执行静态代码块、静态变量初始化等操作）。编译期常量，指的是「在Java代码编译阶段就能确定其最终值」的常量，无需等到程序运行，编译器就能明确其具体值，并对其进行优化（如常量折叠）。原因：编译期常量的值会嵌入到引用类的字节码中，B类编译后，字节码中已经是100，修改A类后，若不重新编译B类，B类会一直使用嵌入的旧值。
2026-05-18 09:01:25
555
原创 native方法的使用与JNI入门
加密解密、音视频编解码、图像处理、AI推理、高性能数值计算，C/C++无GC开销、内存可控，速度远超Java；踩过什么内存泄漏、JVM崩溃的坑？：内存管理、CAS、内存屏障、线程调度、锁实现、unsafe内存操作，全部依赖native；平台强绑定，Windows、Linux、ARM架构库互不兼容，部署、打包、适配成本极高。C/C++没有GC、没有内存保护，野指针、内存越界、段错误、内存泄漏，会直接。native 到底是什么？：网卡、串口、硬件驱动、原生文件IO、系统调用，Java无法直接操作；
2026-05-17 09:01:38
498
原创 transient关键字与序列化排除字段
transient和final可以一起修饰成员变量，语法上不会报错，但transient的“排除序列化”效果会失效——因为final变量（尤其是编译期常量）在编译时就会确定值，反序列化时会自动恢复该常量值，不管是否加transient。这是最容易混淆的点：很多人以为“static变量需要用transient修饰才能不序列化”，其实完全错误——static变量属于类，不属于对象，而序列化的核心是“序列化对象的状态”，因此static变量。transient修饰static变量毫无意义，因为它本来就不序列化。
2026-05-16 09:00:33
637
原创 Java严格浮点计算：strictfp关键字
Java中的Math类，其浮点数方法（比如Math.sin()、Math.pow()）使用的是默认浮点计算模式，不受strictfp关键字的控制——哪怕你给包含Math方法的类/方法加了strictfp，Math类的内部计算依然可能使用硬件优化，导致结果有细微差异。很多人担心“使用strictfp会影响性能”，其实在现代JVM（JDK8及以上）中，这种性能损耗非常小——因为硬件浮点优化的提升本身就有限，而且strictfp只是禁用了中间精度优化，不会增加额外的计算步骤，日常开发中完全可以忽略。
2026-05-15 09:00:17
576
原创 断言（assert）的使用场景与注意事项
很多开发者对断言的理解停留在“简单校验”层面，要么滥用断言替代业务校验，要么不知道如何正确开启、合理使用，甚至踩中“生产环境断言失效”“断言表达式有副作用”等坑。断言表达式中，严禁写“改变变量状态、执行IO操作、数据库操作、接口调用”等有副作用的代码——关闭断言后，这些代码会被直接跳过，导致业务逻辑行为不一致。生产环境默认关闭断言，若用断言做业务入参校验，会导致校验逻辑完全失效，非法参数直接流入业务流程，引发严重bug。以下是断言的4个核心适用场景，每个场景都结合实战场景说明，帮你精准判断何时能用。
2026-05-14 09:00:23
757
原创 Java可变参数的使用规范与限制
在Java中，枚举的构造器有特殊限制，不能使用可变参数——因为枚举常量的初始化是在类加载时完成的，可变参数底层的数组初始化会与枚举的加载机制冲突，编译报错。可变参数的规范看似简单，但新手很容易踩坑，尤其是参数位置、重载相关的规范，一旦违反，要么编译通不过，要么运行出问题。可变参数的类型是固定的，调用时只能传入「同类型的零散参数」或「同类型的数组」，不能传入不同类型的参数，否则编译报错。时，编译器不知道“1,2”是可变参数，还是“1”是可变参数、“2”是name，会产生歧义，所以直接禁止这种写法。
2026-05-13 09:01:24
382
原创 内部类全解：成员、局部、静态、匿名
因为局部变量的生命周期，和局部内部类的生命周期可能不一致：方法执行完，局部变量就会被回收，但局部内部类的实例可能还存在（比如被返回出去），此时内部类访问的变量已经不存在了，所以Java要求变量必须是final，保证变量的值不会变化，即使变量被回收，内部类也能访问到固定的值。匿名内部类中的this，指向的是「匿名内部类自身的实例」，而不是外部类的实例。核心总结：静态内部类（不依赖外部，最常用）、成员内部类（依赖外部，能访问私有）、局部内部类（方法内，几乎不用）、匿名内部类（无类名，简化回调，最常用）
2026-05-12 09:00:44
633
原创 Java的值传递：为什么说只有值传递？
方法内部能修改的，要么是“副本的值”（不影响原变量），要么是“副本地址指向的对象属性”（影响原对象，但不影响原引用）——永远改不了原变量本身（无论是基本类型变量，还是引用类型变量）。但如果朋友把复制的钥匙，换成了别人家的钥匙（修改副本的地址，指向新对象）——你的钥匙依然能打开你家的门，不会受到任何影响（原引用变量不变）。你把钥匙复制了一把，给了朋友（传递的是钥匙的副本 = 值传递）。朋友用复制的钥匙，打开了你家的门，把家里的家具换了（修改对象的属性）——你回家后，看到的就是换了家具的家（原对象属性变化）。
2026-05-11 09:01:14
753
原创 代码块执行顺序：静态、实例、构造器
很多开发者只记“静态先于实例，实例先于构造器”的表面口诀，却不懂底层执行逻辑，遇到“多静态块、多实例块、继承+变量初始化混合、子类构造器隐式调用父类”等复杂场景时，就会彻底混乱，甚至写出逻辑错误的代码。• 对象初始化阶段：每次new子类对象，先执行父类的实例资源（变量+代码块+构造器），再执行子类的实例资源（变量+代码块+构造器），执行两次；：父静态变量→父静态代码块→子静态变量→子静态代码块→父实例变量→父实例代码块→父构造器→子实例变量→子实例代码块→子构造器。
2026-05-10 09:01:11
523
原创 Java包机制与类加载路径问题
不同Jar包、不同包下的同名类，只要全限定类名不同，就会被视为不同的类，由对应的类加载器加载，不会冲突；包机制和类加载路径的底层关联，在于JVM的「双亲委派模型」——类加载器加载类时，会根据"全限定类名"（包名+类名）去查找类，而双亲委派机制决定了"哪个类加载器去加载这个类"，进而影响类的加载结果。：Java语法不支持导入默认包的类，即使其他包的类和默认包的类在同一个项目中，也无法通过import导入，只能使用全限定类名，但默认包没有包名，无法写全限定类名，导致跨包调用完全无法实现。
2026-05-09 09:00:52
617
原创 static关键字的6个常见误区
连续 new 三次对象，count 直接累加到 3，而不是每个对象各自为 1。等认知模糊，日常写 Bug、面试翻车，大多都是踩了 static 的坑。静态变量、静态方法是归每个对象所有，创建越多实例，静态变量就有多份副本。static 修饰的成员，全局只一份，归属于类，不属于任何对象。静态变量全局只有一份，自带同步，多线程修改也不会有并发问题。只要 new 一次，就强行覆盖静态变量，全局状态被随意改动。父类有静态方法，子类写一个同名同参静态方法，就是重写。静态变量在哪赋值都一样，构造器、普通代码块随便改。
2026-05-08 09:00:37
547
原创 final关键字的三种用法与内存语义
的三种用法对应“类不可继承、方法不可重写、变量不可再赋值”，每一种用法都有明确的设计意图和应用场景，下面结合代码案例详细解析。：JMM特殊内存语义，禁止重排序、保证初始化安全、实现无锁安全发布，是并发编程的轻量级保障；，既能写出简洁易维护的代码，又能规避并发安全问题，是Java高级开发的必备技能。：声明时赋值、实例初始化块赋值、构造器赋值（三选一，必须在构造器结束前完成）；的标准写法，编译期直接赋值（常量折叠优化），运行时不可修改，命名规范为。指对象在多线程间共享时，避免其他线程看到不完整或不一致的状态。
2026-05-07 09:00:22
281
原创 枚举进阶用法：超越常量的设计模式应用
由JVM保证线程安全，无需手动实现饿汉式/懒汉式的线程安全逻辑——这是枚举实现单例模式的核心优势，也是《Effective Java》推荐枚举单例的根本原因。以"订单支付手续费计算"为例，不同支付方式（支付宝、微信、银行卡）手续费规则不同，传统写法会导致if-else嵌套，新增支付方式需修改原有代码，违反开闭原则。在订单状态、支付策略、配置管理、日志处理等场景中，优先使用枚举实现设计模式，既能提升代码质量，又能降低维护成本，是Java高级开发的必备技能。若常量超过20个，建议拆分枚举或用数据库配置。
2026-05-06 09:01:05
366
原创 反射机制：强大但危险的Java魔法
Java反射机制，是Java语言提供的一种能力，允许程序在运行时，动态获取类的完整信息（包括类名、父类、接口、属性、方法、构造器），并动态创建对象、调用方法、修改属性，无需在编译期提前知晓类的具体实现细节。：反射的底层，是JVM在加载类时，会在方法区生成一个唯一的Class对象（包含类的所有元数据），反射API就是通过操作这个Class对象，实现对类的动态操控——这也是反射能"透视"类的关键所在。程序运行时，通过反射动态加载插件中的Class对象，创建实例、调用方法，实现功能扩展。
2026-05-05 09:00:14
323
原创 Java I/O流性能对比：NIO、BIO、AIO该如何选择？
AIO是Java 1.7引入的异步非阻塞I/O模型（也叫NIO.2），核心是「异步非阻塞+回调通知」，是真正意义上的"异步I/O"——线程发起I/O操作后，立即返回，无需等待、无需轮询，由操作系统完成I/O操作后，通过回调函数通知线程处理结果。光说理论不够，我们做一组实测，模拟「1000个并发连接，读取100KB文件」的场景，对比三者的性能（测试环境：Linux服务器，JDK 17，4核8G），数据更直观。流是单向的，读写分离，操作繁琐。"非阻塞"，是指线程在等待I/O事件时，不会一直阻塞，可做其他事情。
2026-05-04 09:00:26
351
原创 注解全攻略：从使用到自定义注解处理器
注解（Annotation）是Java 5引入的一种元数据机制，用于给类、方法、字段、参数、包等Java元素打上"标签"，本身不直接影响代码的执行逻辑，但可以被编译器、虚拟机、框架或自定义工具（注解处理器）读取和解析，进而实现特定的功能。框架注解的本质，就是"用注解标记Java元素，再通过反射或注解处理器解析注解，实现特定的框架逻辑"，和我们前面写的实战案例原理完全一致。通俗理解：注解就像给代码贴的"便利贴"，我们贴上去之后，编译器、框架或自己写的工具，会根据便利贴上的内容，自动做对应的处理。
2026-05-03 09:03:11
558
原创 Java泛型深度解读：类型擦除的利与弊
例如，要实现一个通用的集合容器，只能存储Object类型的对象，取出时必须手动强制转换类型——这不仅导致代码冗余，更严重的是，强制转换可能引发ClassCastException，且这种错误只能在运行时发现，无法在编译期提前规避。对于Java开发者来说，掌握类型擦除的原理和利弊，不仅能帮助我们规避开发中的错误，更能让我们理解Java泛型的设计思想——软件设计中没有"完美的方案"，只有"最适合的方案"。可以看出，Java的类型擦除是"兼容性、性能、简洁性"三者的折中——它不完美，但最适合Java的生态现状。
2026-05-02 09:30:39
273
原创 异常处理最佳实践：从try-catch到自定义异常
另一个容易出错的地方是finally块中抛出异常，如果try块中也有异常抛出，那么try块中的异常会被finally块抛出的异常覆盖。异常处理是Java开发中不可或缺的技能。从基础的try-catch-finally语法，到multi-catch的优雅简化，再到try-with-resources的自动资源管理，以及自定义异常的灵活运用，每一层都有其适用的场景和最佳实践。需要注意的是，finally块在资源关闭之后执行，所以如果资源关闭时抛出异常，这个异常会在catch块处理完try块中的异常之后被抛出。
2026-05-01 17:30:00
844
原创 Java数据类型陷阱：int和Integer的7个关键区别
在64位JVM中，对象头大约占用16字节，加上4字节的整数值，总共约20字节，远大于。栈内存的特点是访问速度快，但空间有限，且生命周期较短。由于它直接存储值，不需要对象头开销，访问速度非常快。这是Java虚拟机自动初始化的结果，当你声明一个类成员变量但没有赋值时，Java会自动将其初始化为。堆内存的特点是空间较大，生命周期较长，但访问速度相对较慢。是Java的8种基本数据类型之一，它直接存储数值本身，没有对象头开销。这是一个非常容易出错的地方。直接存储值，不需要额外的引用和解引用操作，因此访问速度非常快。
2026-05-01 10:01:14
567
原创 别再乱用 String 了：String、StringBuffer、StringBuilder 全解析
在 Java 开发中，字符串处理是最常见的操作之一。然而，很多开发者对 String、StringBuffer 和 StringBuilder 的区别和使用场景并不清晰，导致在不经意间低效地处理字符串，影响程序性能。因为 String 经常被用作 HashMap 的 key，在频繁的 hash 计算中，如果每次都重新计算会非常耗时。字符串处理是 Java 开发中最常见的操作之一，理解 String、StringBuffer 和 StringBuilder 的区别，选择合适的工具，能让你的代码性能提升千倍。
2026-04-30 17:30:00
656
原创 Java中的==和equals()，你真的分清了吗？
由于list存储的是s1对象，而非"java"字符串字面量，所以用字符串去查找是找不到的。很多人脱口而出：“==比较的是引用，equals()比较的是值。既然Object的equals()默认比较地址，那为什么我们用equals()比较字符串时，比较的却是内容？"equals()在Object类中默认就是用==实现的，所以默认情况下也比较地址。所以，在没有重写equals()的类上，equals()和==的行为是一模一样的。"==对于基本类型比较的是值，对于引用类型比较的是内存地址。
2026-04-30 09:00:42
500
原创 SpringBoot消息积压排查：监控与扩容策略
更为严重的是，当消息积压到一定程度后，即使消费者恢复正常，也需要相当长的时间才能消化积压，形成"处理真空期"。然而，当消息消费速度跟不上生产速度时，就会出现消息积压（Message Backlog）问题，轻则导致系统响应延迟，重则引发服务雪崩。比如一个订单消息的处理需要查询用户信息、库存信息、物流信息，涉及多次数据库查询和外部服务调用，单条消息处理时间可能达到数百毫秒，当订单量突增时，积压不可避免。当消息积压严重，系统面临崩溃风险时，可以采取限流措施，限制部分消息的处理速率，保证核心业务的正常运转。
2026-04-29 17:30:00
322
原创 SpringBoot 消息事务：事务消息与最终一致性
欢迎在留言区分享你的经验！用户下单后，订单数据成功写入数据库，但通知库存服务扣减库存的消息却发送失败...，掌握事务消息与最终一致性的实现方案！RocketMQ 提供了完善的分布式事务消息支持，采用"半消息"机制。在本地数据库中创建消息表，记录待发送的消息，通过定时任务重试发送。利用 Kafka 自身的事务特性，实现消息发送与本地事务的原子性。支付成功后，账户余额已扣除，但订单状态却还是"待支付"...如果支付失败，商品必须放回货架，这就是事务的原子性。是指在发送消息的同时，确保消息发送与本地事务的。
2026-04-29 09:00:43
550
原创 SpringBoot 消息顺序性保证：分区与顺序消费
分区机制作为解决这一问题的主流方案，通过巧妙的架构设计，在可接受的性能损耗范围内实现了消息顺序性的保障。当多个消费者同时处理来自同一业务流的消息时，处理结果的顺序将取决于各消费者线程的执行速度，而非消息的原始顺序。在采用分区机制的消息队列（如 Kafka、RocketMQ）中，生产者发送消息时需要指定分区键，消息队列根据分区键将消息路由到不同的分区。调查显示，不同课程的消息使用了不同的课程ID作为分区键，导致同一学生的消息被分散到不同分区，不同消费者的处理速度差异造成了顺序错乱。是顺序性要求最严格的领域。
2026-04-28 17:30:00
303
Python微信防撤回小程序
2019-11-28
空空如也
TA创建的收藏夹 TA关注的收藏夹
TA关注的人