自建的 RustDesk 非常好用，给巨佬加个 star ，感谢 🎉

同意 OP 决定.
流程转交楼下

UID: 1138024568
solana: 9raUVuzeWUk53co63M4WXLWPWE4Xc6Lpn7RS9dnkpump

6

挺好看的，点赞👍

m1 mac 连续不关机使用一个月会变卡，每月需要关机一次才行~

试试 Typora ，全选网页内容复制，然后粘贴到 Typora 创建的 md 文件里面，会自动转换，图片也会创建对应目录保存

ODEzNjE4OTFAMTYzLmNvbQ==

@hn16838220 ThreadLocalMap 就是被 Thread 绑定的。这句话我没有表达清楚
你题目中：为什么 ThreadLocalMap 不直接放在线程中呢
其实，ThreadLocalMap 就是放在线程 Thread 类中的，线程 Thread 类中的 threadLocals 变量就是 ThreadLocalMap 。

虽然 ThreadLocalMap 的源代码在 ThreadLocal 中，但其实它是被 Thread 拥有维护的，就像假设有两个人 A （ ThreadLocal ）、B （ Thread ），A 有枪的图纸（ ThreadLocalMap ），但真正造出来的枪（ threadLocals ，即 ThreadLocalMap 类的对象）是属于 B 的，A 只负责造枪，但枪的拥有者是 B

ThreadLocalMap 就是被 Thread 绑定的。

之所以泄漏是因为用的是 Tomcat 自带线程池，默认一直运行了 200 个线程。
这些线程默认都有一个变量名为 threadLocals 的 ThreadLocalMap ，ThreadLocal<T> 的 set 方法是往 Thread 的 threadLocals （就是 ThreadLocalMap ） put key 为 ThreadLocal ，value 为 <T>（ ThreadLocal 的泛型对象 T ），如果在一次请求中 set 后忘了调 ThreadLocal 的 remove() 方法，那么请求的 Thread （由于是 Tomcat 线程池中的 Thread ，所以在应用运行过程中一直存在）的 threadLocals 的 key 为 ThreadLocal 的对象就不会被清除，就会出现内存泄漏的问题。

如果直接 new 了一个普通的 Thread ，那么不会出现内存泄漏的问题，因为 普通的 Thread 不会一直运行，GC 会回收

异步写的日志为啥需要回滚？
这个需求好奇怪呀，不想在日志表里看出错的日志？
一般不是需要看日志中的标识字段查询请求的处理结果是否成功嘛？

正常来说：代码出错了应该会报异常，对异常做回滚处理，而在日志表一般直接是用相关标识字段来标识（比如 Is_success_flag ）请求是否处理成功，比如 Is_success_flag 为 1 ，那么请求是成功的，Is_success_flag 是 0 ，那么请求是失败的（失败也可以把出错信息记录到另一字段存储）。

为啥需要回滚呢？？？

@amwyyyy 找到一圈 issue 终于找到原因了，不是数据结构的问题，原因是由于日志配置的问题引起的：日志配置不能配置为异步输出

文笔可以。

可用模版方法模式解决：基础类同属性的校验规则写在父类的钩子函数中，如果业务子类不需要覆盖，那么钩子函数不需要重写，如果业务子类需要覆盖，那么就进行重写，这样可以兼容变化和不变的代码

耳机盒缝隙较大，用手左右移动会疙瘩疙瘩响，换过一次还是老样子......
不过降噪确实可以。

@lmshl 不想背八股文😂，只是想研究下什么业务下用哪个隔离级别更合适~

这是目前我在网上找到的一篇一定程度下解惑的相关性文章： https://www.zhihu.com/question/47007926/answer/2264785785

原文搬运到此（侵删）

真实的场景可以注意一下，代码里面，有没有出现连续 2 次 select 的场景。

那为什么会出现连续 2 次 select 的场景，第二次不能复用第一次的结果吗？
这个主要是因为写代码的时候，第一次 select 和第二次 select 很可能不在一个方法里面。要复用，就要在第一个方法里面 return 这个结果，再传给第二个方法。有时候觉得这样写太难看了，干脆就查两次算了，反正小业务不用考虑啥性能的。这个也可以认为是用性能换取代码可读性，代码可维护性。（ PS：不过个人还是不喜欢这样查两次，可以再想想办法，在不影响代码可读性上查一次）

另外，讨论幻读和可重复读的问题，很多时候可能都在考虑选 RR 还是 RC 的问题。

选 RR 还是 RC 首要考虑的是业务逻辑上会不会出错。
1.一个判断就是有没有两次 select
2.另外一个就是要注意 RR 虽然能解决可重复读，幻读的问题，但是并不意味着代码就不出错。有点像 java volatile 虽然能保证可见性，但不是说用 volatile 就能解决并发问题这个道理。

举个例子说：现在 RC 级别，一个业务失败了可以记录表等待重试，也可以直接取消掉。定时任务拉取了现在记录表等待重试的记录，结果后面重试又失败了，原因是被直接取消掉了。心想为啥呢，要是被取消了，定时任务也拉不起来呀，这个原因就是拉起来后，中途马上被别人改掉了，重试的时候冲突发生了错误。

这个时候可能心想：哦，原来是读到了别人取消的信号。那简单，直接改成 RR ，保持我这次业务逻辑的正确性（定时任务拉取到，就要能修改），如果是这样做，最后数据库这行记录变成了：取消标志位：true ；执行状态：success 。人傻了。。。

还有一个场景就是，更新余额的时候。像在上上个公司，更新余额的时候，是事务里面，select for update 查出数据，然后减少余额，应用里算出余额的值，最后 update 。这个不管是 RC 还是 RR 级别，都没问题，因为 select for update 锁行了。

像在上个公司，更新库存的时候，开了 RC 级别事务，更新的时候，代码里没有像 select for update 锁行，而是在更新语句中 update 表 set 现在的库存=原来的库存-要扣的数量。这个也没问题。

但是如果你数据库是 RR 级别，没有用 select for update 锁住行，是在应用层算出最后新值，然后再直接 update 这个新值。心里想着，那现在总没问题了吧，RR 级别，可重复读，我这个业务的计算可是正确的。但是实际上也是有问题的，会把别人的覆盖掉。

所以总的来说，RR 和 RC 我一般会先看下有没有两个 select ，也就是明显的幻读，可重复读问题。另一个会看下会不会有可重复读的问题解决了，本次业务能够保证正确性，但是在更大的维度上可能会出错（把别人的覆盖了）

PS：不过上述的考虑我觉得还是有点偏理论偏学生，站在更加实际，现实的角度：
1 、小项目的话，直接默认 RR ，因为没有业务，我没理由改 RC 。改 RC 可能还会有潜在的我不知道的错误（因为毕竟不是默认的），前期需要研发速度，需要尽量简单快速落地
2 、项目变大了，想要 RR 改 RC 。不敢改。项目变大了，稳字优先，稳字当头
3 、想要利用 RR 改 RC 提升性能，没有其他技术手段了吗，非要改这个？
4 、没有其他技术手段了，那就改吧