- 博客(21)
- 收藏
- 关注
原创 Spring Boot 请求处理链路
在 Spring Boot 的标准模型中,你可以放心使用来优化代码架构,但必须遵循以下模式:Java// 使用拦截器形成完整的生命周期闭环@Component@Override// 入口:初始化环境@Override// 出口:必须清理,防止线程池污染Tomcat 的线程池是一个“激进”的池子,它优先创建线程而非优先排队。这提高了 Web 响应速度,但也意味着对的清理要求达到了“强迫症”级别,因为任何一次遗忘都会导致线程池中的某个线程被“污染”。
2026-02-10 10:14:03
902
原创 ThreadLocal为什么会内存泄漏
内存泄漏的根源不在于,而在于没有及时清理不再使用的 Entry。在线程池环境下,这种风险会被无限放大。JVM 并不是专门针对Map进行分析,而是将其视为一个普通对象。但由于Map的结构(内部数组 -> Entry节点 -> 具体的Key/Value),它形成了一个庞大的引用树。只要树根(Map 变量)还在 GC Roots 的覆盖范围内,整棵树上的所有 Key 和 Value 都会被标记为“活跃”,从而占据堆内存。你不用担心在方法内部正常使用时 Key 消失,因为你的局部变量就是最坚强的“强引用”盾牌。
2026-02-10 09:57:21
661
原创 流媒体中I、B、P帧是什么
帧类型完整性压缩率参考对象I 帧完整低 (大)无 (独立)P 帧不完整中前一帧B 帧不完整高 (小)前一帧 + 后一帧“只要能通过‘移动旧像素’来描述‘新画面’,且当前不需要强制刷新,就产生 P 帧。特性短 GOP (例如 1s)长 GOP (例如 10s)压缩率较低(I 帧多,费空间)极高(P/B 帧多,省空间)实时性延迟低,适合直播延迟高,适合本地存储容错性强(花屏闪烁一下就恢复)弱(一旦花屏可能糊半天)快进找帧极快,拖动流畅较慢,可能卡顿。
2026-02-09 11:36:50
774
原创 Java AQS
原始的 CLH 锁是一种基于链表的、高性能的自旋锁。核心思想:每个想要获取锁的线程都被封装成一个节点(Node)。自旋观察:线程不直接观察锁的状态,而是观察前驱节点的状态。逻辑每个节点都有一个locked变量。当一个线程尝试获取锁时,它先将自己的locked设为true。然后它不断地看前一个节点的locked是否为false。一旦前驱释放了锁(变为false),当前线程就开始执行。特性原始 CLH 锁AQS 变体队列等待方式循环自旋(费 CPU)挂起/阻塞(省 CPU)链表方向。
2026-02-04 16:28:12
808
原创 Java atomic和volatile的区别
在 Java 并发编程中,volatile和atomic(通常指包下的原子类)是处理线程安全的两种常用手段。简单来说:volatileatomic。
2026-02-04 16:08:08
394
原创 Flutter异步原理
特性Isolate执行线程在主线程(Main Isolate)中轮询在新的后台线程中运行适用场景网络请求、文件 I/O、简单的异步等待复杂计算、解析超大 JSON、视频解码内存共享共享主线程内存内存隔离,通过 Port 传值异步函数的同步性async函数在遇到第一个await关键字之前的代码完全是同步执行的,不会有任何延迟。链式触发之后的代码(例如)必须等待doSth彻底完成后,作为一个微任务(Microtask)被排进队列执行。.then的时机的内容会在get3。
2026-02-03 11:23:34
1034
原创 Flutter渲染原理
Flutter 之所以快,是因为它绕过了原生控件(OEM Widgets)。传统原生开发:Dart -> 原生桥接 -> 原生控件 -> 操作系统绘图。Flutter:Dart -> 渲染引擎 -> GPU。Flutter 就像一个自备画板和画笔的画家,它不需要向操作系统借用任何按钮或文本框,它直接在屏幕上“画”出一切。了解了布局原理后,你就能理解为什么有时候给一个组件设了width: 100却不起作用——因为父组件传下来的“强制约束”优先级更高。只触发 Paint“小额消费”。
2026-02-03 10:57:48
1048
原创 Flutter三棵树
Flutter三棵树机制解析:Widget、Element和RenderObject协作实现高效UI渲染。Widget作为轻量级配置描述UI,Element负责状态管理和差异对比(Diff算法),RenderObject处理实际布局绘制。关键点:1)Diff算法通过对比Widget类型和Key决定复用或重建;2)Key在列表操作中保证状态正确迁移;3)三棵树分工实现声明式编程与性能优化的平衡。理解这一机制可避免常见性能问题和状态管理错误。
2026-02-02 10:37:38
336
原创 MediaCodec解码器核心运作流程
MediaCodec 的工作就是**“空桶拿来 -> 装料推走 -> 熟桶拿来 -> 用完还桶”**的无尽循环。
2026-02-02 10:24:02
254
原创 Flutter Riverpod原理
实现跨 Widget 状态共享的核心在于“状态与 UI 分离”和“状态集中管理”。它将状态从 Widget 树中抽离出来,由一个独立的、全局可访问的容器进行托管和调度。这种方式不仅解决了状态共享的问题,还带来了出色的可测试性和类型安全。
2025-11-06 11:29:45
815
原创 Kafka Rebalance策略
策略工作原理优点缺点适用场景Range按主题逐个分配,计算n/consumer实现简单容易负载不均,尤其多主题时默认场景,主题和分区数较少所有分区全局轮询负载最均衡要求消费者订阅主题相同所有消费者订阅完全相同的主题Sticky追求均衡且最小化变更均衡且大幅减少Rebalance开销算法复杂生产环境首选,尤其频繁启停消费者时你可以实现。
2025-09-16 18:06:12
650
原创 联合索引下一些Mysql中容易理解错误的概念
最左匹配原则(Leftmost Prefix Principle)是数据库联合索引(多字段索引)的核心工作机制,指,不连续或跳过左侧字段的条件无法利用索引,直接影响查询效率。
2025-09-16 14:37:11
641
原创 堆存储文件分析
字段Shallow Size 计算逻辑Retained Size 计算逻辑对象头(12B) + 引用字段(6 * 4B=24B) + 填充(4B) = 40B自身(40B) + 所有独家支配的子对象总和 = 96BString (sn)固定结构:对象头+字段(hash,value引用,coder等)=24B自身(24B) + 其独家支配的byte[3]byte[3]对象头(12B)+长度(4B)+数据(3B)+填充(5B)=24B。
2025-09-15 19:01:01
1691
原创 Java对象内存布局全解析
若对象头 + 实例数据总大小不是 8 的倍数,则需填充至最近倍数。子类会包含父类的所有字段(包括私有字段),父类字段优先排列。数组对象额外包含 4 字节存储数组长度(即使关闭压缩指针)。高频创建的小对象(如 Kafka 消息)应尽量轻量化;指向方法区中对象的类元数据(Class 信息)。),将引用指针从 8 字节压缩至 4 字节。对象的所有成员变量(包括父类继承的字段)。头(12) + 字段 + 填充(8对齐)头(12) + 引用(4) + 填充。(大于 21 的最小 8 倍数)
2025-09-15 17:16:26
747
原创 Mysql中的char和varchar
特性CHAR(n)VARCHAR(n)长度类型固定长度可变长度空间占用始终占用n字符空间(有填充)占用:实际字符数 + 1~2字节(长度记录)空格填充存储时填充空格到指定长度n不填充空格尾部空格处理读取/比较时 通常去除 尾部空格尾部空格保留并参与比较存储效率长度固定不变时高;变化大时浪费大长度变化大时显著节省空间性能理论上固定位置操作可能快一点现代优化后差异极小。
2025-09-01 10:45:39
721
原创 原始快照(SATB)和增量更新(Incremental Update)
在垃圾回收(尤其是并发标记阶段)中,“漏标” 指的是并发标记过程中因应用线程修改对象引用,导致部分存活对象未被标记,最终被错误回收的问题。解决漏标的核心是跟踪并发标记期间的引用变化,确保所有存活对象都被正确标记。拦截引用修改操作,结合后续的补充标记阶段解决漏标问题,只是跟踪的侧重点不同,分别适应不同垃圾收集器的设计目标(如低延迟、高吞吐量)。SATB 是 G1、ZGC 等垃圾收集器采用的策略,核心思想是。,确保快照中的存活对象都被标记,即使后续引用发生变化。,确保新引用指向的对象被重新标记。
2025-08-21 10:41:43
1773
原创 G1垃圾收集器回收过程
G1 通过 “Region 划分”“并发标记”“收益优先的筛选回收” 实现了高吞吐量与低延迟的平衡,核心是在控制停顿时间的前提下,优先回收垃圾最多的 Region。其过程结合了新生代回收和混合回收,通过 Remembered Set 和 SATB 机制优化了标记效率,是 JDK 9 及以上默认的垃圾收集器,适用于大堆内存(如 8GB 以上)的应用场景。避免 Full GC 的长时间停顿,分批次回收老年代垃圾(如每次回收 10% 的高收益 Region)。(默认 200ms)调整回收策略,适应实时系统需求。
2025-08-21 10:30:20
1592
原创 G1会产生浮动垃圾吗
G1必然产生浮动垃圾:根源在于并发标记阶段用户线程的活动及SATB的保守策略。优化建议根据业务负载调整-XX:InitiatingHeapOccupancyPercent,避免堆占用过高;合理设置-XX:MaxGCPauseMillis,利用G1的软实时特性平衡吞吐量与停顿;监控Full GC频率,避免退化(如增大堆空间或降低阈值)。浮动垃圾是G1为实现低延迟付出的必要代价,但通过增量回收和动态调优,其影响远低于CMS,更适应高并发场景。
2025-08-20 23:17:26
683
原创 CMS为什么会产生浮动垃圾
根本原因:用户线程在并发标记和清理阶段持续运行,新产生的对象/垃圾无法被当前回收周期覆盖影响:可能导致空间不足和Concurrent Mode Failure优化方向:降低触发阈值(如),预留更多空间;或升级至G1/ZGC等支持全并发整理的收集器简言之,CMS的并发设计在减少STW的同时,牺牲了对"动态新垃圾"的实时处理能力,这是其追求低延迟的典型权衡。
2025-08-20 23:11:47
448
原创 Redis事务
Redis事务提供轻量级的原子操作,适合简单批量命令,但缺乏回滚和复杂逻辑支持;高并发或需条件判断的场景应优先选择Lua脚本。结合WATCH的乐观锁可有效解决超卖等并发问题,但需注意错误处理和数据补偿。
2025-08-20 22:45:58
337
原创 实现单例的几种方式
单例模式(Singleton Pattern)是一种创建型设计模式,其核心目标是确保一个类在整个应用程序生命周期中只有一个实例存在,并提供全局访问点。这种模式在需要控制资源访问、共享配置信息或管理全局状态时尤为重要。
2025-08-20 22:11:08
244
空空如也
空空如也
TA创建的收藏夹 TA关注的收藏夹
TA关注的人
RSS订阅