最近又在卷八股文，直呼卷不动了啊。这个行业啥时候才能不这么卷？？？

Java volatile

说起八股文，volatile绝对是个老八股，随便拉个人来都能说上两句，什么内存可见性、内存屏障、指令重排序。。。真搞不懂调包侠整这些玩意有啥用。

既然卷就卷到底，看看这玩意底层到底是在干啥。

公司员工餐选用的美餐平台，但是经常由于太忙忘记点餐，导致饿着肚子加班。反正菜品的可选项比较少，想着要是能自动点一个就好了。于是有了以下脚本。

接口分析

参数分析

自动点餐无非就是模拟人的行为，自动请求一些关键接口。于是分析了一下美餐网的web端接口，发现关键接口如下：

1. 获取菜单接口：https://meican.com/preorder/api/v2.1/restaurants/show?tabUniqueId=???&targetTime=???&restaurantUniqueId=???&client_id=???&client_secret=???
2. 下单接口：https://meican.com/preorder/api/v2.1/orders/add?client_id=???&client_secret=???

有了接口只是第一步，第二步开始分析、尝试接口的哪些参数是静态的，哪些是动态的。

世界上只有一种共识协议，就是 Paxos，其他所有共识算法都是 Paxos 的退化版本。

Paxos分为Basic Paxos、Multi Paxos、和其它演进版本。

Basic Paxos

前提：Basic Paxos 只能对单个值形成决议。

Paxos 算法将分布式系统中的节点分为三类：

• 提案节点：称为 Proposer，提出对某个值进行设置操作的节点，设置值这个行为就被称之为提案（Proposal），值一旦设置成功，就是不会丢失也不可变的。请注意，Paxos 是典型的基于操作转移模型而非状态转移模型来设计的算法，这里的“设置值”不要类比成程序中变量赋值操作，应该类比成日志记录操作，在后面介绍的 Raft 算法中就直接把“提案”叫作“日志”了。
• 决策节点：称为 Acceptor，是应答提案的节点，决定该提案是否可被投票、是否可被接受。提案一旦得到过半数决策节点的接受，即称该提案被批准（Accept），提案被批准即意味着该值不能再被更改，也不会丢失，且最终所有节点都会接受该它。
• 记录节点：被称为 Learner，不参与提案，也不参与决策，只是单纯地从提案、决策节点中学习已经达成共识的提案，譬如少数派节点从网络分区中恢复时，将会进入这种状态。

之前不想把博客里面的图片也一同上传，用了utools里面一个默认的免费图床，结果今天发现好像图床挂掉了。之前写的博客里面的图片全挂了。。。果断换了gitee做新的图床。

这不会再挂了吧。。。

2022-05-20 更新

真是没想到,gitee关闭了public库,这下图床又挂了…已经申请了公开库的申请…不知道会不会通过.

2022-05-23 更新

gitee回复了,图床类的库不给公开.gg了.

天天都在用的Mybatis，为啥调用一个Mapper接口就能执行SQL，你有没有想过这个问题？

这一切都得从 @MapperScan 这个注解开始说起。打开这个注解定义可以看到：

相信Chrome浏览器开发者工具中的Preview你不陌生，但是就这玩意有一个bug。

事情是这样的，前端跟我说你接口有bug，返回的数据不正确。听到bug，我反手就是一个你会不会用。

引入

在Java8之前创建一个线程的写法（之一）：

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21

public class LambdaTest {



    public static void main(String[] args) {

        new Thread(new Runnable() {

            @Override

            public void run() {

                System.out.println("hello inner class!");

            }

        });

    }

}

简介

ThreadLocal一个特殊变体，当从FastThreadLocalThread访问时，可获得更高的访问性能。
在内部， FastThreadLocal在数组中使用常量索引来查找变量，而不是使用哈希码和哈希表。 尽管看似非常微妙，但与使用哈希表相比，它在性能上却有一点优势，并且在经常访问时很有用。
要利用此线程局部变量，您的线程必须是FastThreadLocalThread或其子类型。 由于这个原因，默认情况下， DefaultThreadFactory创建的所有线程均为FastThreadLocalThread 。
请注意，只有在扩展FastThreadLocalThread线程上才可以使用快速路径，因为它需要一个特殊的字段来存储必要的状态。 任何其他类型的线程的访问都回退到常规ThreadLocal 。

上面这段描述来自FastThreadLocal源码中的文档，从中可以知道FastThreadLocal必须和FastThreadLocalThread或其子类型一起使用才可以达到Fast的效果。

批量更新的方式有很多种，例如update case when，foreach update等，今天在使用其中一种foreach update时一直报SQL语法错误，看了半天没看出哪里有问题:

前段时间偶尔会收到线上MySQL死锁告警通知，由于有补偿机制，最终业务会处理成功，所以没太关心。

1

Caused by: com.mysql.jdbc.exceptions.jdbc4.MySQLTransactionRollbackException: Deadlock found when trying to get lock; try restarting transaction

最近又收到了相同的告警，可能不是偶然事件，于是开始排查。
首先翻看了日志，结合代码，没有发现什么问题。事发时应该也没有什么大批量并发事件。