abcnull 的博客

能够控制 callThirdPartyAPI 内的执行逻辑是均匀分布在 0.0s、0.1s、0.2s…0.9s, 1.0s, 1.1s…一些业务场景中，我使用 java 在后端代码中可能要对某些流程做频率控制，其实会有很多做法，不同的做法适用于不同的场景。比如服务端代码假如要调用某个 open api，这个 api 会有一定的频控，你不想要触发到这个频控。一些简单的对某些流程执行的频率控制。

常规的集合类，比如 ArrayList，HashMap 当作为多线程下共享的变量时候，操作它们时会涉及线程安全的问题。典型应用：存储热点数据，避免重复计算；适合：读多写少的场景（因为写操作时复制底层数组，读操作无需加锁）适合：需要频繁读写的线程安全的场景。

它为了解决多线程环境下资源的竞争问题。通过互斥锁机制，确保同一时间只有一个线程可以执行同步的代码。线程对共享变量的修改会立即刷新到主内存中，其他线程可以立即看到最新的值。锁对象：当前类的 Class 对象（如 MyClass.class）锁对象：可以灵活指定（如 this、Class 对象或自定义对象）锁对象：当前实例对象（this）

jvm 规定，每个线程有自己的工作内存（本地缓存），对变量的读写一般在自己的工作内存（本地缓存）中进行，如果一个线程修改了共享变量的值，其他线程可能无法立即看到最新的值，因为工作内存（本地缓存）还未被更新的原因。假设 A，B 线程同时执行，假设按照操作1 - 2 - 3 - 4 这样的操作顺序执行下来，线程B看到 flag == true 时，a 应该已经被赋值为 1，所以 b 的值是 1，输出 1。volatile 声明的变量，写操作时强制将变量的修改立即刷新到主内存；

默认情况下，@Async 使用 Spring 的 SimpleAsyncTaskExecutor 线程池（最大线程数为 Integer.MAX_VALUE），一旦请求激增，有可能会导致 cpu 陡增和内存陡增，导致服务崩溃强烈建议自定义线程池！// 核心线程数 executor . setMaxPoolSize(10);// 最大线程数 executor . setQueueCapacity(100);

使用自定义配置的线程池，// 核心线程数// 最大线程数// 非核心线程空闲存活时间// 有界队列// 拒绝策略，默认就是拒绝策略// 创建自定义线程池unit,workQueue,handler// 创建自定义线程池（周期性执行）unit,workQueue,handlerCPU 密集型：CPU 核心数 + 1（减少上下文切换）IO 密集型：2 * CPU 核心数（线程常阻塞，需更多线程）根据系统资源设置，避免资源耗尽（如 corePoolSize * 1.5）

推荐根据业务需求配置10, // 核心线程数20, // 最大线程数60L, TimeUnit.SECONDS, // 空闲线程存活时间new LinkedBlockingQueue<>(100), // 任务队列new ThreadPoolExecutor.CallerRunsPolicy() // 拒绝策略如果使用自定义线程池，确保在任务完成后关闭线程池（executorService.shutdown()）

事务有多个隔离级别读未提交（问题：脏读/不可重复读/幻读）读已提交（问题：不可重复读/幻读）重复读（问题：幻读）串行化mysql 默认隔离级别为重复读，一般开发中，大多使用读已提交的隔离级别，也有一些采用重复读的隔离级别（具体隔离级别和带来的问题可以具体查明，这里不做赘述）

在分布式场景高并发环境中，无论是抢红包还是减库存，其实本质上都是如何处理高并发中共享资源的问题，保证高并发资源分配的安全性相互学习，如有错误还请指正～

接口的幂等性是指：用户对同一个操作发起多次请求，系统的设计需要保证其多次请求后结果是一致的。常见的如支付场景，连续快速点击两次支付 10 元，不应该扣费 20，第一次应该扣费成功，第二次则应该失败什么场景要考虑幂等性设计在现在公司里头，都在做分布式划分，一个大型系统会拆成比较多的模块，不同的模块用集群来部署，上游服务调用下游服务的形式，比如 rpc 调用，但是由于网络抖动等原因，可能会造成服务迟迟没有响应，用户端可能多次点击再一个就是支付场景也必须得考虑一下幂等性的问题。

文章目录背景goroutine基本使用chanselectclose死锁互斥锁 sync.Mutex基本使用隐患读写锁 sync.RWMutex基本使用背景不要通过共享内存来通信，而要通过通信来共享内存协程golang 中提供 goroutine（协程）机制，写成和操作系统线程并无一对一关系，协程工作在相同的地址空间，go 中通过 channel 来同步协程，协程不是由操作系统内核来控制，而是完全由程序来控制channel 中如果ch中的数据无人接收，就无法再给通道传入其他数据，即 chann

文章目录errgroup 包结构体 group函数 WithContext函数 Wait函数 Goerrgroup 包errgroup 是 go 官方提供的一个额外的库golang.org/x/sync/errgroup，它可以将一个大的任务拆解成多个任务来并发的执行，并且很容易的管控着并发协程的生命周期底层通过 waitgroup 来控制让所有其他协程运行完主协程 wait 才会被放行底层通过 context 的只读 channel 来管控子协程的生命周期，如果有一个子协程有 error 返回，那

文章目录context 简介接口 Context接口 canceler整型 emptyCtx & 函数 Background & 函数 TODO结构体 cancelCtx & 函数 WithCancel结构体 timerCtx & 函数 WithDeadline & 函数 WithTimeout结构体 valueCtx & 函数 WithValueContext 使用建议context 简介为什么要用 context 呢？因为在并发编程中，一般我们可以通过

文章目录谁返回结果最快用谁的结果，一旦返回最快的结果被拿到了，函数就直接解除阻塞往下执行，无需关注其他慢的结果场景：比如说发送几个 goroutine 去请求某一个数据库，谁最快返回，ch 就被阻塞，然后走 default 分支直接退出了func Query(conns []Conn, query string) Result { ch := make(cahn Result) for _, conn := range conns { go func(c Conn) {

文章目录close 解除读取 chan 阻塞深入思考建议扩充close 解除读取 chan 阻塞上方的例子是通过 waitgroup 等待让所有的 goroutine 都运行完毕之后，wait 函数才会被放行（注意加上超时处理）。试想一下存在这样的琴况，如果 wait 函数要等待所有 goroutine 结束才能放行，可是这些 gouroutine 因为从 chan 读取不到数据而造成阻塞，则这些 goroutine 可能一直陷入阻塞，而 wait 函数也一直无法放行，就有可能陷入死锁，所以我们有另一种

文章目录前置知识多协程安全退出粗糙版多协程安全退出完美版golang 中很容易开启多个协程，那开启的这么多协程如何保证在 main 函数结束前这些协程都是安全退出呢（信道都安全关闭），这里我们使用到了 select，close 关闭信道函数以及 sync.WaitGroup 函数前置知识当信道被 close 掉之后，如果信道中有缓存，那么被关闭后是不能写的但是依然可以读取缓存数据，缓存被读完后读到的就是 0；如果信道中没有缓存，那么信道被关闭后直接读到的就是 0多协程安全退出粗糙版func wor

文章目录golang 中对于协程提供了非常多好用的函数，其中 sync.WaitGroup 可以让我们把一批协程当成一组要运行的程序，等这一批程序运行完之后放可以运行后面的程序func function() { // 一些操作 // sync.WaitGroup var wg sync.WaitGroup // 开启一个循环 for i := 0; i < 10; i++ { // wg 加一 wg.Add(1) // 开启一个新协程 go fun() { //

简介net 包提供了可移植的网络 I/O 接口，包括 TCP/IP、UDP、域名解析和Unix 域 socket使用监听常用模版关键函数 Dial Listen Accept端口监听// 监听端口listen, err := net.Listen("tcp", "127.0.0.1:8080")if err != nil { // 处理错误}// 不断循环接收for { // 在没有接收到数据前这里是阻塞的 conn, err := listen.Accept() if err

golang 中存在通道 chan，golang 中有一套比较标准的超时重试机制，但是需要借助 time 包中的函数func main() { c := make(chan int) fmt.Println(time.Now()) // 开启协程，往信道传数据 go func() { tīme.Sleep(time.Second * 4) c <- 0 }() for { select { case <-c: // 如果超时 1s 那么久执行这里

文章目录简介发布订阅模型简介发布订阅模型简写为 pub/sub 模型，消息生产者成为了发布者 publisher，消息消费者成为了订阅者 subscriber。传统生产者消费者模型是将消息发送到一个队列中，发布订阅模型是将消息发布给一个主题与其把发布订阅者模式我更喜欢理解成发布订阅器模式，订阅者更像是一个订阅器，发布者中含有多个订阅器，每个订阅器有自己的一种订阅规则，同时订阅器中会存在多个不同的订阅信息，但是这些订阅信息都是满足该订阅器的订阅规则的发布订阅模型发布订阅支持包package pub

文章目录简介生产者消费者模型简介并发不是并行，并发更多是关注程序设计层面的，并行是程序运行层面的。另外需要注意的是 golang 中对于无缓冲的 channel 在接收到一个数据时候就会直接陷入阻塞但是对于有缓冲的 channel，在 channel 满载后再有一个数进入才会陷入阻塞并发编程中最常见的例子就是生产者消费者模型了，大致就是生产者生产一批数据，放到结果队列中，消费者从结果队列中取出数据来消费，这样生产者和消费者就是两个异步的流程，当结果队列中没有数据，消费者就陷入了饥饿等待的状态，当结果队

文章目录ArrayList非线程安全HashSet非线程安全HashMap非线程安全我们知道我们平常使用的 ArrayList，LinkedList，HashSet，HashMap 都不是线程安全的ArrayList非线程安全想使用线程安全的 ArrayList，我们可以用 Vector 或者如下方式List l=Collections.synchronizedList(new Array...

线程本地存储 python 和 java 区别python 的线程本地存储和 java 的线程本地存储还是有些区别的，python 的线程本地存储需要thread_local = threading.local()，之后通过thread_local.x = 1就表示把 1 存进thread_local.x中了，java 的线程本地存储会new ThreadLocal()对象，然后对对象 se...

文章目录简介创建多线程继承 Thread 类简介进程是资源分配的最小单位，线程时任务执行的最小单位。进程拥有资源，多个线程实现共享该进程资源。不同进程试运行还是死亡不影响其他进程，但是进程中某一线程“卡死”后，该进程也会出问题。一个进程至少包含一个主线程创建多线程继承 Thread 类继承 Thread 类，然后重写其中的 run 方法public class ThreadTest e...

文章目录需求场景ThreadLocal 介绍ThreadLocal 底层原理举例需求场景需要多线程运行程序时候，虽然有很多变量可以是不同线程间通用，但是还是有些变量希望做到线程隔离，每个线程需要自己独有的一些变量的场景模型ThreadLocal 介绍早在 jdk 1.2 的版本中就提供了 java.lang.ThreadLocal 的支持，这个工具可以帮助我们很方便的写出多线程的一些程序...