- 博客(75)
- 收藏
- 关注
RSS订阅原创 学习日报 20250921｜NIO
NIO是Java提供的新I/O API，相比传统BIO具有非阻塞、基于缓冲区和多路复用的特点。核心组件包括Channel、Buffer和Selector，通过示例展示了NIO服务端和客户端的实现方式。服务端使用Selector监听多个通道事件，实现非阻塞通信；客户端通过Channel发送和接收数据。NIO适合高并发场景，是Netty等框架的基础。其优势在于单线程管理多连接，避免了传统BIO的线程资源浪费问题。
2025-09-21 23:19:43
191
原创 学习日报｜线程池 OOM
线程池任务堆积导致OOM的解决方案摘要 核心问题：任务到达速率远超处理能力时，队列堆积引发内存溢出。常见场景包括突发流量、消费阻塞、内存泄漏和隐式线程池。 解决方案： 线程池有界化：设置合理队列容量（maxPool×2~5） 组合策略： 拒绝策略快速失败+告警 入口限流+MQ削峰 超时熔断机制 非关键路径降级 参数建议：core≈CPU核数×(1+阻塞系数)，max=core×2~4 监控体系：线程池活跃数/队列/拒绝数+RT+JVM指标 关键原则：通过有界化、限流、熔断等多重手段，将不确定性控制在系统可承
2025-09-18 21:53:33
289
原创 学习日报｜Spring 全局异常与自定义异常拦截器执行顺序问题及解决
本文分析了Spring Web应用中全局异常拦截器与自定义异常拦截器的执行顺序问题。默认情况下，Spring基于类名ASCII码排序，导致全局拦截器优先执行，与期望的"地方法优先"逻辑不符。文章提出通过改造排序逻辑，优先执行带有包范围限制的拦截器（@ControllerAdvice(basePackages=...)），使精准拦截器优先处理，全局拦截器作为兜底，从而构建更合理的异常处理机制。这种"精准优先+全局兜底"的方案既保证了系统健壮性，又提供了处理灵活性。
2025-09-17 22:50:42
315
原创 学习日报｜梳理三类典型缓存问题：缓存穿透、缓存击穿、缓存雪崩
摘要：本文系统分析了缓存穿透、击穿和雪崩三种典型问题。穿透指请求不存在的数据导致直击数据库，可通过布隆过滤器、空值缓存解决；击穿是热点key失效引发的并发回源，采用互斥锁、逻辑过期等方式防护；雪崩源于大量key同时失效，需TTL随机抖动和多级缓存应对。文章提供了问题特征、治理方案、代码示例和监控指标，并给出不同场景的选型建议，形成了一套完整的缓存问题防护体系。
2025-09-15 23:06:08
784
原创 学习日报｜线程池专题学习总结
线程池是复用线程的容器，通过预先创建线程降低创建/销毁成本。核心参数包括线程数、队列、拒绝策略等。执行流程遵循"核心→队列→扩容→拒绝"四步，状态包含RUNNING至TERMINATED。关键优化点：使用有界队列、合理配置线程数、设置任务超时、监控活跃线程/拒绝数。常见OOM场景包括无界队列堆积、任务泄漏等。最佳实践为：有界队列+显式拒绝+分池隔离+监控告警。注意避免无界队列和无超时调用，通过限流、降级等机制保障系统稳定。
2025-09-14 22:54:56
892
原创 学习日报｜线程池 OOM 案例与优化思路
文章摘要： 线程池使用不当易引发OOM，主要风险场景包括突发流量导致队列堆积、任务执行阻塞、内存泄漏及框架隐式线程池。核心问题在于任务生产速度超过消费能力且缺乏约束。解决方案包括：采用有界队列+合理拒绝策略、接口限流、任务超时控制、实时监控队列及内存指标。优化心法可总结为"限产、有限、超时、可监控"四原则，通过流量管控和资源约束预防潜在风险。
2025-09-14 22:48:08
318
原创 01-手写线程池与模拟OOM
本文介绍了线程池的核心参数及实现原理。线程池主要包含corePoolSize（核心线程数）、maximumPoolSize（最大线程数）、keepAliveTime（空闲线程存活时间）、workQueue（任务队列）和handler（拒绝策略）等关键参数。通过一个手写线程池示例，详细演示了这些参数的工作机制：当任务数≤corePoolSize时创建核心线程；核心线程满后任务进入队列；队列满后创建非核心线程；所有资源满后触发拒绝策略。代码还展示了非核心线程的超时销毁机制。该实现完整模拟了线程池的创建、任务调度
2025-09-14 20:36:09
203
原创 线程池核心参数 — 5W1H1S 解析
线程池核心参数5W1H1S解析摘要（150字） 线程池核心参数包括corePoolSize（核心线程数）、maximumPoolSize（最大线程数）、keepAliveTime（空闲线程存活时间）、workQueue（任务队列）、threadFactory（线程工厂）和handler（拒绝策略）。其作用在于限制资源、提升性能、应对高峰和容错兜底。参数在任务提交、队列满载或线程空闲时动态生效，适用于高并发服务端场景。配置需结合业务类型：CPU密集型任务推荐核心线程数为CPU数+1，IO密集型为2倍CPU数；
2025-09-13 16:39:56
482
原创 随笔20250721 PostgreSQL实体类生成器
摘要：本文介绍了三层架构中异常处理的最佳实践，建议try-catch放在ViewModel层，Service层仅使用业务异常。同时讨论了DbHelper的单例模式实现及批量插入优化方案，强调异步调用链必须从DAO层贯穿到ViewModel层。最后提供了一个PostgreSQL实体类生成工具的实现，通过解析数据库元数据自动生成C#实体类，支持表名转换、数据类型映射和特性标注。工具采用Npgsql连接PostgreSQL，可自动处理表结构、字段类型、主键等元信息，生成符合规范的实体类代码。
2025-07-21 23:00:46
275
原创 隨筆20250519 Async+ThreadPoolTaskExecutor⾃定义线程池进阶实战
1.核心綫程數 查看核心綫程數目是否已經滿，未滿 創建一條綫程 執行任務，已滿負責執行第二部2.阻塞隊列 查看阻塞隊列是否已經滿，未滿將任務加入阻塞隊列， 已滿執行第三步3.綫程池 是否已經達到綫程池數，未滿，常見一條綫程執行任務，已滿 根據策略處理無法執行的任務。关键在于观察程序的瓶颈在哪里：是等待IO操作（例如网络请求、磁盘读写）的时间长，还是CPU计算的时间长。 IO 网络请求: 访问数据库、远程服务器等。 磁盘读写: 读取文件、写入日志等。 用户输入/输出: 等待用户输
2025-05-19 17:01:59
220
原创 随笔 20250413 Elasticsearch 的 term 查询
你的目的推荐查询方式查 "包含 world"✅match查询精确查 "World"（大小写）✅term.keyword（非分词字段）查部分词、模糊匹配✅match需要我帮你分析你 index 的 mapping 吗？你可以贴一下的结构，我可以告诉你字段类型是否支持.keyword，从根上解决 💡。
2025-04-13 22:52:52
495
原创 20250319 工作随笔 水晶报表的修改(.rpx)
Label和TextBox：用于静态文本和动态数据。Line和Shape：用于分割和装饰。Picture：用于插入图片。ReportInfo：用于显示页码、总页数和打印时间等报表信息。使用可以灵活定制ReportInfo的显示格式。
2025-03-19 09:25:51
1047
原创 20250307隨筆 使用 A5 SQL 打开 .a5er 文件以及生成建表語句
文件后，你可以查询某个表的名称以及生成数据表的 SQL 脚本。你可以用这个 SQL 在数据库中创建相同的表。如果你想获取某张表的。
2025-03-07 14:50:12
875
原创 20250305随笔 HTML2Canvas 详解与使用指南
是一个用于将 HTML 页面或特定 DOM 元素转换为 Canvas 画布的 JavaScript 库。它通过解析 HTML 和 CSS，生成等效的 Canvas 图像，从而实现网页截图功能。
2025-03-05 21:42:02
1092
原创 20250226 工作隨筆 C#文件拷貝
並根據不同條件進行校驗與回滾。，並根據不同條件進行校驗與回滾。方面都有了明顯提升 🎯。方面都有了明顯提升 🎯。，表示操作是否成功。，表示操作是否成功。
2025-02-26 16:34:57
1059
原创 20250219 隨筆 [特殊字符] 查看短鏈的實現方式與解決方案優化
透過MQ（消息隊列）配合冗餘雙寫策略來解決分庫分表帶來的解析問題，並確保數據在多庫之間的最終一致性。為減少查詢複雜性並提升查詢效率，將數據按照業務角色分為賣家庫與買家庫。買家庫：賣家庫：目的：確保買家庫與賣家庫之間數據同步，支持多角度高效查詢。具體方案：在分庫分表與冗餘雙寫的場景下，分佈式事務是關鍵問題，尤其是確保數據在多庫間的一致性。問題：解決方案： ✅ 使用 MQ 實現最終一致性優勢：在 分庫分表架構 下，WebRelease 搭配 MQ + 冗餘雙寫 的策略，不僅能解決短鏈解析的庫表定位問題，同時通
2025-02-19 14:46:08
556
原创 20250219 隨筆 [特殊字符] 使用 Sharding-JDBC 時未配置分片規則的表如何通過默認數據源定位？
Sharding-JDBC 是一款來自 Apache ShardingSphere 的分布式數據庫中間件，主要用於支持 分庫分表、分布式事務 和 數據庫治理，且對應用層無侵入。在使用 Sharding-JDBC 時，通常需要為需要分庫分表的表進行分片規則（Sharding Rule）配置。但並不是所有表都需要分片，有些表（如參數表、字典表等）本身數據量較小或不適合分片。當 Sharding-JDBC 檢測到某個表在配置中未定義分片規則時，系統會自動將該表映射到配置文件中聲明的默認數據源。💡 解釋：
2025-02-19 14:36:52
753
原创 20250218 隨筆 垂直分库分表（Vertical Sharding） 和 水平分库分表（Horizontal Sharding）
它们在大规模数据库优化、分布式架构设计中至关重要，主要用于。不同的业务数据存储在不同的数据库中，每个数据库只处理自己相关的业务，提高效率。如果你有具体的业务场景，可以告诉我，我可以给你更详细的架构设计建议！：不同业务拆分到不同数据库，查询、写入性能提升。：数据分布在多个数据库或表，查询、写入速度更快。等功能，如果所有数据都存放在一个数据库。各个数据库可以独立扩展，互不影响。避免单表数据过大，提高查询速度。：可以继续增加数据库或表，支持。查询，需要在应用层处理。，适用于大规模系统架构。：需要分布式事务，如。
2025-02-18 14:34:10
960
原创 20250217 随笔 详细解析 preHandle 方法的作用、流程、优化方案
在 Web 应用中，我们需要对用户请求进行身份认证，防止未授权访问。
2025-02-17 12:03:56
746
原创 20250214 随笔 Elasticsearch（ES）索引数据 vs. 业务数据库冗余双写
都是常见的数据同步方案。在高并发数据查询场景下，
2025-02-14 13:04:14
1177
原创 20250214 随笔 Nginx 负载均衡在数据库中的应用
如果系统使用多个独立的 MySQL 实例（无主从关系），我们可以让数据库请求均匀分布到不同的数据库上，防止某个实例负载过高。在高并发环境下，数据库的性能往往是系统的瓶颈。为了提高数据库的吞吐能力、优化请求分配、减少单点故障，我们可以使用。，它允许我们将数据库请求分发到多个数据库服务器上，从而提高并发能力，减少某一台数据库的压力。这就是完整的文章内容，现在你可以轻松复制了！在数据库架构设计中，我们可以利用 Nginx 进行。，里面可以包含多台数据库服务器。，以及不同场景下的最佳实践。是主要的数据库实例，而。
2025-02-14 10:44:24
1238
原创 20250213 隨筆 自增id與業務id
中，通常会在业务表（Business Table）中。，由于它们是随机生成的，会导致索引分裂，影响性能。中，自增 ID 可能会带来。，这样做的目的是为了兼顾。
2025-02-13 16:04:05
762
原创 20250213 随笔 PV（Page View） 和 UV（Unique Visitor）
是两个常见的访问统计指标，它们用于衡量短链的流量情况。在短链（短网址）系统中，
2025-02-13 14:03:02
465
原创 20250213 隨筆 雪花算法
但使用時需要考慮機器 ID 分配、時鐘同步等問題。如果業務場景對 ID 長度較為敏感，則可以考慮基於雪花算法的變種方案來縮短 ID 位數。在 2010 年開發的一種。如果 64-bit ID。
2025-02-13 12:41:39
1016
原创 20250213 隨筆 讀寫分離（Read-Write Splitting）
讀寫分離 是一種 資料庫架構優化方案，它的核心思想是 將「寫操作」和「讀操作」分離，分別交給不同的資料庫伺服器處理，以提高性能、擴展性和並發能力。在傳統的單一資料庫架構中，所有的 增、刪、改、查（CRUD）操作都發生在同一個資料庫上，這樣會導致：為了解決這些問題，我們使用「讀寫分離」架構，讓：通常，讀寫分離使用 主從（Master-Slave）架構 來實現，典型架構如下： Master 負責寫入：所有的寫操作（INSERT/UPDATE/DELETE）都發送到 主庫，並同步到從庫。 Slave 負
2025-02-13 09:34:31
813
原创 20250212 ThreadLocal
以下是一篇介紹的文章，包含了從「HTTP 請求與執行緒」的背景，到的用途、原理和使用注意事項的完整說明。
2025-02-12 14:25:43
991
原创 20250124 Flink 增量聚合 vs 全量聚合
以下通过对比 **增量聚合** 和 **全量聚合（ProcessWindowFunction）** 的工作机制，结合具体示例解释其原理和优势。| **场景** | **增量聚合** | **全量聚合** |Long sum = iterable.iterator().next();- **增量聚合**：仅保存聚合中间结果（如 `sum=100`, `max=50`）。
2025-01-24 14:36:33
2042
原创 20250120 Flink 中的 Rescaling 算子
可以把 Flink 的 Rescaling 想象成一家工厂的生产线。如果工厂原本有 5 条生产线，但由于订单增加，需要增加到 10 条生产线，那么工厂就会对生产资源进行重新分配。类似地，Flink 的 Rescaling 就是调整流处理任务中“工人”的数量。就是 Flink 中对任务的并行度（Parallelism）进行调整的过程。简单来说，就是在任务运行时或重新部署时，改变 Flink 应用中算子的工作线程数量，使其能够更好地适应数据量的变化或资源的可用性。
2025-01-20 16:53:21
743
原创 20250120 Flink 的 缓冲区超时（Buffer Timeout）
机制确实类似于一辆车等待乘客的过程，如果车每次只载一个乘客就发车，会导致效率低下，资源浪费。同样，在Flink的数据流处理中，缓冲区超时的设置对吞吐量和延迟的权衡至关重要。通过合理配置缓冲区超时，可以在Flink中实现吞吐量和延迟之间的最佳平衡。选择缓冲区超时值时，需要根据应用的。
2025-01-20 13:15:34
1111
原创 20250120 深入了解 Apache Flink 的 Checkpointing
当任务因故障而中断时，Flink可以从最近一次成功的Checkpoint恢复，继续任务执行，而无需重新处理已经完成的数据。当任务重启时，Flink会从最近的偏移量开始重新消费数据，确保数据不会丢失或重复处理。在实时流处理任务中，保证数据的一致性和任务的容错性是至关重要的，而Flink的。如果你正在使用Flink进行实时流处理任务，Checkpoint是你必须深入了解和掌握的关键机制！通过合理配置Checkpoint，可以确保Flink作业在高负载和分布式环境下的可靠运行。
2025-01-20 13:07:19
2035
空空如也
空空如也
TA创建的收藏夹 TA关注的收藏夹
TA关注的人