- 博客(21)
- 收藏
- 关注
RSS订阅原创 线程安全的List
中的读取操作是完全无需加锁的。更加厉害的是，写入操作也不会阻塞读取操作，只有写写才会互斥。CopyOnWriteArrayList是JUC（并发编程常用包）的很重要的类，是线程安全的List。ArrayList和LinkedList是线程不安全的List这个是大家都熟悉的吧。默认是没有提供包的，但是我们可以从线程安全的角度来思考，线程并发的时候加锁即可。如果学过相应的八股大家就会知道——这个其实本质上是线程不安全的类。当然是有的——就是进行加锁——但是我们如果不希望手动的管理锁呢？
2025-07-01 21:54:34
110
原创 RBAC权限模型
一个用户可以访问n个菜单，一个菜单可以属于n个用户——很典型的 n:n的关系，如果直接控制数据库无非就是 简历一个 user-menu表 用来体现 n:n 的关系。role1会有menu1、menu2权限，那么role就会和menu表集成 role_menu权限表给默认的role赋值权限。如果这个情况下对每个用户访问，都需要加入一定权限，同时这个是菜单的权限，如果是数据的权限呢？几乎是最常用的权限模型了，个人开发者/小公司的从0-1搭建一个项目，这个权限模型几乎是属于必学的知识了。1. RBAC权限模型。
2025-07-01 15:37:39
159
原创 分布式系统的分析（补偿和理论）——以Xxl-Job为例
如果在提交之后，执行之前宕机了——根据作者仔细分析了一手源码，这个是没办法保证的——算是一个风险项但是概率极低——只有在——本地事务update完，异步执行线程时，同时第一条的落库语句不插入（时间窗口极短），才会出现数据丢失的问题。（2）本机的调度中心宕机——Xxl-Job采用的是悲观的锁，且在事务入口处进行锁定只有一个实例操作，后续的操作都基于这个事务，假设宕机，数据全量回滚，选择新的主节点执行时间轮独占执行操作，问题不大。：执行与原始操作相反的撤销操作，适用于无法继续的业务场景。
2025-07-01 15:02:57
399
原创 Xxl_Job源码走读触发线程详解
后续add任务的时候用来判断是否加入慢队列或者快队列进行任务。快慢线程池，保证Xxl_Job高可用高性能的重要手段。在进行触发线程分析之前我们先看看这个代码。还记得第一篇的那个触发参数吗。
2025-06-21 18:55:00
119
原创 阿里场景题——如何设计一个热度系统
选型：Mysql、MQ、Xxl_Job（MQ和Xxl_Job会组成一个执行器项目，可以看我的定时任务那一篇）方案的核心是不能接受Redis的意外宕机，因为Redis的宕机时候数据同步代价太高、同时数据也不能接受平白无故丢失。3、执行器项目会扫描任务表，找到对应的时间，相应的发MQ消息，业务层进行监听消费即可。
2025-06-21 14:01:08
341
原创 线上接口分析多维度思考
原先的流程是 先看服务的调用、再看机器的CPU情况、随后看DB的压力均衡情况、如果上述都平稳看clickHouse链路的Trace情况，定位位置、如果是SQL的问题去看慢日志、分析索引、分析语句。（2）SQL的查询优化——从SQL语句本身出发（链表查/JOIN的时候考虑JOIN的索引）（4）业务代码是否某环节调用时间过长，是内存计算有问题还是什么原因（例子）（2）能否进行数据缓存（本地缓存或者Redis的中间件数据缓存）（3）锁竞争情况分析（当然对于select来说相对会少一点）（1）能否用异步调用优化。
2025-06-17 11:17:29
423
原创 流程引擎扩展自定义功能
先完成一个策略接口，对于策略接口进行详细的实现，然后需要的参数校验和别的逻辑校验放置于最顶层，最后顶层抽象出一个入口方法 ， 反射代理这个方法即可。（2）看引擎有没有预留扩展的接口 如果有预留 可以再预留处进行自己的代码扩展——这个就不会违反开闭原则——对修改关闭对扩开放。3. 如果需求简单 是在调用完流程引擎的API 然后 再处理后续的业务代码 是完全没有问题的。（1）如果引擎没有预留的位置 但是你的这个需求很重要 —— 尝试解耦。（2）反射 本地反射代理业务层的方法，去进行方法执行——如果代码逻辑。
2025-06-16 14:28:11
279
原创 MQ之队列阻塞怎么办
3. 业务场景抽象出来之后 —— MQ用的是并行消费，生产者发送的时候根据业务属性随机分发到共有队列——于是笔者就很自然得想到了——我要提升消费能力——我要开更多的线程并发处理业务。5. 贴主得业务场景最后抽象之后 MQ消费之后要进行DB得落库操作——机制的你一定发现问题了——我测——DB压力太大怎么办——当然机架组会有措施滴，会给你限流得——但是这个不可行。——回到问题的根源——我们为什么堵了——线上分析是因为某些用户得量太大了！——So 当然是限制消费者啦。因此，八股要活学活用！
2025-06-05 00:29:46
309
原创 与MQ有关的高可用和高性能
三者协同作用，既保护系统资源（如CPU、数据库连接），又避免雪崩效应，最终实现高可用性与弹性——在流量高峰或部分故障时，以可控的“有损服务”维持整体运行，如电商秒杀时限流、支付服务熔断后转异步处理，大促期间降级非关键功能，从而平衡性能、资源与用户体验。几个点需要明确：业务上的限流你要衡量场景，不是什么东西都能被丢弃的（电商场景的限流可能是在顶端限流，牺牲部分用户体验——没干过这个场景我猜的哈，错了指正）——但是对于许多服务来说——万万不可得罪甲方——所以限流就并非指的是拒绝连接了。业务上我们能走优化嘛？
2025-06-04 00:34:54
262
原创 如何应对线上故障
不过实际分析的时候，我们会去看当时是对象哪个占的大，随后有historym去看调用的线程，查看哪个线程发生了问题，追踪线程的操作，当时在干什么，找到问题线程之后，拿当时的相关信息，进行翻译转义，最后结合业务特点进行代码的修改即可。MQ是不是本身就有三次重试？这个时候有同学就会问了，主播主播，你的降级确实很有东西，但是跨系统非自产自销的怎么办呢，你不能强制对方给你弄个接口吧？首先是共有的，既然不能完全信任MQ，那么我们代码块中一定要有try catch（当然了，主流的MQ客户端一定会有异常抛出的）
2025-06-03 01:00:39
419
原创 面试——Java 手撕多线程相关题目
最近发现写博客真的是一种缓解压力的好方式，他能把你所会的，所学的一起输出给大众看（虽然可能也没人看罢）但是看着自己的知识输出在大众视野下终归让人感到心安，笔者也会慢慢把这半年自己的笔记输出于大众。一般面试的手撕分很多种 SQL、力扣、还有就是Java的实操，今天也是闲着没事，来记录一下实操中的经典题——多线程相关的题目。（4）手写死锁代码——这个笔者写过，打算偷个懒用以前的代码了。两个线程交替打印1~100的奇数和偶数（使用。的计数器，并解释ABA问题的解决方案（如。BlockingQueue实现。
2025-06-02 01:19:11
151
原创 设计模式——模板模式
模板方法模式（Template Method Pattern），又叫模板模式(Template Pattern)，在一个抽象类公开定义了执行它的方法的模板。它的子类可以按需要重写方法实现，但调用将以抽象类中定义的方式进行
2025-06-01 14:30:11
545
原创 面试题——定时任务数据过大如何处理
本文探讨了基于Xxl-Job的定时任务处理方案，针对高时间要求任务和时间不敏感任务提出了解决方案。针对业务定时任务，提出了利用Xxl-Job和RocketMQ共同抽象的通用业务定时任务执行器的解决方案。该执行器职责单一，只负责记录定时时间，到点发送MQ给业务进行消费，有效解决了定时任务执行量大的问题。通过任务分片和队列分发，可以实现高效的定时任务执行，保证业务的顺利进行。
2025-06-01 02:10:00
1306
原创 函数式编程之Function实际代码运用
函数式编程是种编程方式，它将电脑运算视为函数的计算。函数编程语言最重要的基础是λ演算（lambda calculus），而且λ演算的函数可以接受函数当作输入（参数）和输出（返回值）实际上函数式编程的目的是为了把实际实现推迟到主函数实现，底层只定义泛型，这个例子其实不能很好体现，所以我再写一个实际场景用的。照例写在前言 一切以实操为准，概念如果有错误请见谅。接下来就是Function接口。
2025-05-31 23:36:48
134
原创 设计模式——策略模式
它定义了算法家族，分别封装起来，让它们之间可以互相替换，此模式让算法的变化独立于使用算法的客户端。代码希望优雅，设计模式当然是不可少的，我将分文章一篇篇讲解我理解的设计模式和实际使用的思路。3. 实现上一般都是枚举类+Map+接口去实现的完全消除 if else if。说人话就是用接口类加上实现类，代替if else if 把行为进行封装。策略模式（Strategy Pattern）是一种行为型。
2025-05-30 16:57:12
219
原创 附代码—Redis+异步线程以解决查询耗时的场景
本文讨论了在实际应用中缓存一致性的必要性，并提出了一种轻量级的缓存优化方案。作者首先介绍了在使用Redis解决查询耗时问题时需要了解性能瓶颈的情况，并强调了优化方案需要结合实际场景进行分析。在具体方案设计中，提出了基于超时时间设置和异步线程进行短时间更新的方案。论证了为什么不采用更新数据库删缓存或延时双删策略，强调了数据一致性要求不高且可容忍秒级数据不一致的场景。实际使用中，作者通过代码示例演示了如何利用RedisService和主服务代码实现该缓存优化方案，保证数据的及时更新和一致性。
2025-05-30 15:07:07
358
原创 MongoDB——SQL慢查询线上问题分析
本文介绍了在解决数据库查询性能问题时的一般步骤。首先，需要定位问题，查看监控工具的线上流量和服务器健康情况，以及实际调用量。然后，可以使用MongoDB的Explain工具进行慢查询分析，类似于MySQL的Explain。通过分析索引走向、执行计划等信息，可以找到潜在的问题，并考虑重建索引或创建联合索引来优化性能。在解决问题时，需要评估风险并考虑业务特点，确保解决方案有效且不会对现有服务造成不必要的影响。
2025-05-30 11:39:45
602
空空如也
空空如也
TA创建的收藏夹 TA关注的收藏夹
TA关注的人