日期: 2021 年 5 月 29 日

服务器BMC知识介绍

在介绍BMC之前需要了解一个概念，即平台管理（platform management）。

平台管理表示的是一系列的监视和控制功能，操作的对象是系统硬件。比如通过监视系统的温度，电压，风扇、电源等等，并做相应的调节工作，以保证系统处于健康的状态。当然如果系统真的不正常了，也可以通过复位的方式来重新启动系统。同时平台管理还负责记录各种硬件的信息和日志记录，用于提示用户和后续问题的定位。以上的这些功能可以集成到一个控制器上来实现，这个控制器被称为基板管理控制器（Baseboard Manager Controller，简称BMC）。

需要说明的是，BMC是一个独立的系统，它不依赖与系统上的其它硬件（比如CPU、内存等），也不依赖与BIOS、OS等（但是BMC可以与BIOS和OS交互，这样可以起到更好的平台管理作用，OS下有系统管理软件可以与BMC协同工作以达到更好的管理效果）。

一般我们的电脑不会带BMC，因为用处不大，一些温度、电源等的管理，CPU（或者EC，这就是另外一个话题了）来控制就够了。但是对于系统要求高的设备，比如服务器，就会用到BMC。当然因为BMC是一个独立的系统，对于某些嵌入式设备，可能不需要其它处理器，光一个BMC就能完成工作。

说到底BMC本身也是一个带外处理器（一般都是ARM处理器）的小系统，单独用来处理某些工作也完全是可以的。不过这里既然叫做BMC，那么总的来说重点还是在平台管理，所以本文主要说的是服务器中的BMC。BMC在系统中的位置大致如下图所示：
%title插图%num

BMC通过不同的接口与系统中的其它组件连接。

LPC、I2C、SMBUS，Serial等，这些都是比较基本的接口，而IPMI，它是与BMC匹配的总线，所有的BMC都需要实现这种接口，这里需要特别的介绍。

IPMI
IPMI的全称是Intelligent Platform Management Interface，智能平台管理接口。

看了名字也不需要特别介绍它用来干什么的了，关于它的详细介绍可以参看https://www.intel.com/content/www/us/en/servers/ipmi/ipmi-home.html，这里只做简单的介绍。

IPMI规定了很多的东西，BMC是其中*重要的一个部分，此外还有一些”卫星“控制器通过IPMB与BMC相连，这些”卫星“控制器一般控制特定的设备。

IPMB全称Intelligent Platform Management Bus，是一种基于I2C的串行总线，它用于BMC与”卫星“控制器的通信，其上传递的是IPMI命令。

下面的图描述了与IPMI有关的各个模块：
%title插图%num

下面简单的介绍各个部分。

MOTHERBOARD

首先是图中的左下角部分，名称写着Mother Board。

%title插图%num

通常，在服务器中，这一部分是主角，它包含了CPU，PCH等主要的部件。

这里我们可以看到它连接除了数个组件：网卡，串口和IPMI总线，其实还有一个部分在图中*上面中间的PCI总线。

网卡：服务器需要用到网卡，这个本身没有什么好介绍的，重点其实在于BMC到网卡的连接，后续会介绍。

串口：串口用于输出服务器的调试信息，但是这里值得注意的是其中的Serial Port Sharing，它使得服务器的串口输出可以直接输出，也可以输出到BMC。至于为什么要输出到BMC，这里其实需要注意的是一种常用的场景。服务器位于机房，而工作人员通常不会直接在机房操作，而是通过网络（这也是为什么BMC会连接网卡的原因）进行操作，这个时候过需要获取服务器的串口信息，就不方便直接去机房，这个时候通过BMC来获取服务器串口信息就是一个好主意。

IPMI总线：这是BMC与服务器通信并进行控制的主体，当然少不了。

PCI总线：这个部分的作用跟串口很像。服务器除了输出串口信息，当然还需要输出图形界面之类的东西。从服务器端来看，它通过PCI连接的就是一个显卡，通过它来输出显示。

 

IPMB
再来到图中的右上角，其中描述的是通过IPMB连接的设备。
%title插图%num

这些设备跟BMC类似，也是用来进行管理芯片。

它们是对BMC的补充，从而扩展BMC的功能。

 

Non-volatile Storage
我们知道BMC其实是一个独立的芯片，那么它肯定也需要运行系统。

通过BMC里面运行的是一个类Unix系统，而该系统就存放再Non-volatile Storage中，通常就是SPI Flash里面。
%title插图%num

跟一般的存储介质没有本质的区别。

除了系统本身之后，还包含一系列BMC会存放的信息。

比如从服务器上面获取到的串口信息；系统本身的报警信息；FRU信息等。

 

Sensors & Control Circuitry
这一部分虽然图中只占很小的一部分，但却是BMC*基本的功能：获取信息和控制环境。
%title插图%num

BMC会通过I2C/PECI等总线去获取设备的温度，然后根据预先设定的策略去调整温度。

调整的方式两种，一种就是调整风扇，属于主动降温；另一种是调整供电，比如CPU的P状态，或者关闭多余的硬盘等，属于被动降温。

 

FRU
FRU的全称是Field Replaceable Unit。
%title插图%num

从图中也可以看出，类似内存条，CPU等就属于FRU，它们在服务器中通常是可以更换的。

BMC会检测这些设备并保存相关的信息。

当这些设备的在位情况发生变化时，BMC会发生相关的告警。

游戏服务器是干什么的

在做游戏服务器开发之前之前一直有疑问，服务器是干什么的？问了几位前辈，得到的答案大概都是：服务器就是一台电脑，你可以访问，然后做一些事情（我现在觉得这个答案是很精辟的）。这个答案对于之前的我来说，由于根本没接触过服务器，不能理解其中的含义。百度得到的答案也不是我想要的。

现在做游戏服务器开发两个月了，分享一下自己对游戏服务器的理解，希望能以另外的角度给想做游戏服务器开发的新人一些不同理解方向。如果有什么说的不对的地方，请见谅。

游戏服务器其实就是处理游戏逻辑的（这话说的，新手谁看的懂啊。 = =！）

举个大话例子：餐厅
将一个餐厅点菜比喻成一个游戏，桌子上有菜单，菜单上有：鱼香肉丝，清蒸牛肉，有一位客人看了菜单之后点了一道菜（鱼香肉丝）后，服务员将这道菜名告诉了厨房，厨房做好菜后递给服务员，*后服务员给你端上来了。

在这个游戏中，餐桌相当于游戏的客户端，厨房相当于游戏服务器，服务员相当于客户端与服务器的通信，客人相当于玩家。

客户端：桌子上的菜单和上的菜（鱼香肉丝），这些都是客户端给玩家显示的。

服务器：当菜名到达了厨房之后的一系列操作都是服务器做的（厨房开始准备，切菜，炒菜，完成后，告诉服务员，让他把菜端出去）。

做这个游戏的服务器开发，就相当于，增加餐厅能提供的菜。比如餐厅要求增加一道番茄炒蛋的菜，你就要教会厨房怎么弄番茄炒蛋，确保经过你的调教之后，厨房在收到这个菜名时一定能做出这道菜，或者做不出菜的时候会给客户端提示（卖完了之类的）游戏就能更新，客户端就会在菜单上新增加一道番茄炒蛋的菜，客人就能点这道菜。

出现bug又是个什么情况呢？例如你在调教厨房做这道菜时，只教会了厨房做菜，没有做什么别的操作。当点了这道菜，然后番茄用完了，这时候厨房由于你只教厨房做菜，没告诉它出现这种情况怎么办，厨房就不知道怎么办（出现了bug），*后客人一直在等，*后却没有上这道菜。

 

举个实际游戏例子：简单描述斗地主的一个简单流程
当你（玩家2）的上家（玩家1）出了一个3，轮到你出牌，你手上有345JK。

客户端：1.显示三位玩家的牌，你的上家和下家的牌都是背对着你的。

2.显示你的手牌，供你选择。

3.收到服务器发来的消息（玩家1出了3），显示给你看。

这时候你点了一个3，然后点击出牌。客户端——->服务器，玩家2出个3。

服务器：1.收到客户端发来的消息（玩家2出3）。

2.判断你是否能出这张牌。

3.将判断结果（不符合出牌规则，不许出）返回给客户端。

这时候客户端收到消息。

客户端：1.显示提示：你出的牌不服务规范。（这张牌一直出不去）

这时候你点了一个4，然后点击出牌。客户端——->服务器，玩家2出个4。

服务器：1.收到客户端发来的消息（玩家2出4）。

2.判断你是否能出这张牌。

3.将判断结果（可以出牌）返回给客户端。

这时候客户端收到消息。

客户端：1.你的手牌少了一张4。

2.牌桌上多了一张4。

然后轮到下一家出牌。

 

在这些例子中，服务器做的事情，都是需要游戏服务器开发人员通过代码来实现的。回到我几位前辈对我的回答：服务器就是一台电脑（电脑是硬件服务器，写的游戏服务器是软件，需要有硬件载体），你可以访问（客户端连接服务器），然后做一些事情（玩家出了一张3，请服务器告诉我，可不可以出）。

以上就是对游戏服务器的理解，希望能给你提供一个理解游戏服务器是干什么的思路。如果有什么说的不对的地方，请指出，我会尽快修改。

使用 v-cloak 防止页面加载时出现 vuejs 的变量名

使用 vuejs 做了一个简单的功能页面，逻辑是，页面加载后获取当前的经纬度，然后通过 ajax 从后台拉取附近的小区列表。但是 bug 出现了，在显示小区列表之前，会闪现小区名对应的 vuejs 变量名。

案发现场的 HTML 代码

  1. <ul v-for=“item in items”>
  2. <li>{{ item.name }}</li>
  3. </ul>

页面加载时，会闪现

{{ item.name }}

Google 了一下，发现 vuejs 内置的 directive v-cloak 可以解决这个问题。非常简单

HTML 修改成

  1. <ul v-cloak v-for=“item in items”>
  2. <li>{{ item.name }}</li>
  3. </ul>

CSS 中添加

  1. [v-cloak] {
  2. display: none;
  3. }

搞定！

但是原理是什么呢？

这段 CSS 的含义是，包含 v-cloak (cloak n. 披风，斗篷；vt. 遮盖，掩盖) 属性的 html 标签在页面初始化时会被隐藏。

在 vuejs instance ready 之后，v-cloak 属性会被自动去除，也就是对应的标签会变为可见

Redis缓存穿透、缓存雪崩、redis并发问题分析

把redis作为缓存使用已经是司空见惯，但是使用redis后也可能会碰到一系列的问题，尤其是数据量很大的时候，经典的几个问题如下：

(一)缓存和数据库间数据一致性问题

分布式环境下（单机就不用说了）非常容易出现缓存和数据库间的数据一致性问题，针对这一点的话，只能说，如果你的项目对缓存的要求是强一致性的，那么请不要使用缓存。我们只能采取合适的策略来降低缓存和数据库间数据不一致的概率，而无法保证两者间的强一致性。合适的策略包括 合适的缓存更新策略，更新数据库后要及时更新缓存、缓存失败时增加重试机制，例如MQ模式的消息队列。

(二)缓存击穿问题

缓存击穿表示恶意用户模拟请求很多缓存中不存在的数据，由于缓存中都没有，导致这些请求短时间内直接落在了数据库上，导致数据库异常。这个我们在实际项目就遇到了，有些抢购活动、秒杀活动的接口API被大量的恶意用户刷，导致短时间内数据库宕机了，好在数据库是多主多从的，hold住了。

解决方案的话：

1、使用互斥锁排队

业界比价普遍的一种做法，即根据key获取value值为空时，锁上，从数据库中load数据后再释放锁。若其它线程获取锁失败，则等待一段时间后重试。这里要注意，分布式环境中要使用分布式锁，单机的话用普通的锁（synchronized、Lock）就够了。

public String getWithLock(String key, Jedis jedis, String lockKey, String uniqueId, long expireTime) {
 // 通过key获取value
 String value = redisService.get(key);
 if (StringUtil.isEmpty(value)) {
 // 分布式锁，详细可以参考https://blog.csdn.net/fanrenxiang/article/details/79803037
 //封装的tryDistributedLock包括setnx和expire两个功能，在低版本的redis中不支持
 try {
 boolean locked = redisService.tryDistributedLock(jedis, lockKey, uniqueId, expireTime);
 if (locked) {
 value = userService.getById(key);
 redisService.set(key, value);
 redisService.del(lockKey);
 return value;
 } else {
 // 其它线程进来了没获取到锁便等待50ms后重试
 Thread.sleep(50);
 getWithLock(key, jedis, lockKey, uniqueId, expireTime);
 }
 } catch (Exception e) {
 log.error("getWithLock exception=" + e);
 return value;
 } finally {
 redisService.releaseDistributedLock(jedis, lockKey, uniqueId);
 }
 }
 return value;
}

这样做思路比较清晰，也从一定程度上减轻数据库压力，但是锁机制使得逻辑的复杂度增加，吞吐量也降低了，有点治标不治本。

2、布隆过滤器（推荐）

bloomfilter就类似于一个hash set，用于快速判某个元素是否存在于集合中，其典型的应用场景就是快速判断一个key是否存在于某容器，不存在就直接返回。布隆过滤器的关键就在于hash算法和容器大小，下面先来简单的实现下看看效果，我这里用guava实现的布隆过滤器：

<dependencies> 
 <dependency> 
 <groupId>com.google.guava</groupId> 
 <artifactId>guava</artifactId> 
 <version>23.0</version> 
 </dependency> 
</dependencies> 
public class BloomFilterTest {
 
 private static final int capacity = 1000000;
 private static final int key = 999998;
 
 private static BloomFilter<Integer> bloomFilter = BloomFilter.create(Funnels.integerFunnel(), capacity);
 
 static {
 for (int i = 0; i < capacity; i++) {
 bloomFilter.put(i);
 }
 }
 
 public static void main(String[] args) {
 /*返回计算机*精确的时间，单位微妙*/
 long start = System.nanoTime();
 
 if (bloomFilter.mightContain(key)) {
 System.out.println("成功过滤到" + key);
 }
 long end = System.nanoTime();
 System.out.println("布隆过滤器消耗时间:" + (end - start));
 int sum = 0;
 for (int i = capacity + 20000; i < capacity + 30000; i++) {
 if (bloomFilter.mightContain(i)) {
 sum = sum + 1;
 }
 }
 System.out.println("错判率为:" + sum);
 }
}
成功过滤到999998
布隆过滤器消耗时间:215518
错判率为:318

可以看到，100w个数据中只消耗了约0.2毫秒就匹配到了key，速度足够快。然后模拟了1w个不存在于布隆过滤器中的key，匹配错误率为318/10000，也就是说，出错率大概为3%，跟踪下BloomFilter的源码发现默认的容错率就是0.03：

public static <T> BloomFilter<T> create(Funnel<T> funnel, int expectedInsertions /* n */) {
 return create(funnel, expectedInsertions, 0.03); // FYI, for 3%, we always get 5 hash functions
}

我们可调用BloomFilter的这个方法显式的指定误判率：

Redis缓存穿透、缓存雪崩、redis并发问题分析

 

private static BloomFilter<Integer> bloomFilter = BloomFilter.create(Funnels.integerFunnel(), capacity,0.01);

我们断点跟踪下，误判率为0.02和默认的0.03时候的区别:

Redis缓存穿透、缓存雪崩、redis并发问题分析

 

Redis缓存穿透、缓存雪崩、redis并发问题分析

 

 

对比两个出错率可以发现，误判率为0.02时数组大小为8142363，0.03时为7298440，误判率降低了0.01，BloomFilter维护的数组大小也减少了843923，可见BloomFilter默认的误判率0.03是设计者权衡系统性能后得出的值。要注意的是，布隆过滤器不支持删除操作。用在这边解决缓存穿透问题就是：

public String getByKey(String key) {
 // 通过key获取value
 String value = redisService.get(key);
 if (StringUtil.isEmpty(value)) {
 if (bloomFilter.mightContain(key)) {
 value = userService.getById(key);
 redisService.set(key, value);
 return value;
 } else {
 return null;
 }
 }
 return value;
}

(三)缓存雪崩问题

缓存在同一时间内大量键过期（失效），接着来的一大波请求瞬间都落在了数据库中导致连接异常。

解决方案：

1、也是像解决缓存穿透一样加锁排队，实现同上;

2、建立备份缓存，缓存A和缓存B，A设置超时时间，B不设值超时时间，先从A读缓存，A没有读B，并且更新A缓存和B缓存;

public String getByKey(String keyA,String keyB) {
 String value = redisService.get(keyA);
 if (StringUtil.isEmpty(value)) {
 value = redisService.get(keyB);
 String newValue = getFromDbById();
 redisService.set(keyA,newValue,31, TimeUnit.DAYS);
 redisService.set(keyB,newValue);
 }
 return value;
}

(四)缓存并发问题

这里的并发指的是多个redis的client同时set key引起的并发问题。比较有效的解决方案就是把redis.set操作放在队列中使其串行化，必须的一个一个执行，具体的代码就不上了，当然加锁也是可以的，至于为什么不用redis中的事务，留给各位看官自己思考探究。

FastJSON实现详解

还记得电影《功夫》中火云邪神的一句话：天下功夫，无坚不破，唯快不破。在程序员的世界中，“快”一直是大家苦苦修炼，竞相追逐的终*目标之一，甚至到了“不择手段”、“锱铢必较”的地步。

一直使用json游离于各种编程语言和系统之间。一个偶然的机会碰到了Fastjson，被他的无依赖、易使用、应用广等特性深深吸引的同时，更被他出奇的“快”所震惊，在Java界犹如一骑*尘，旁人只能望其项背。很自然的一个想法涌上心头：FastJSON为何如此之快？于是定神来拔一拔其实现，一则膜拜大师的杰作，二则虚心偷技，三则方便来者学习。

本篇接下来的内容是基于FastJSON 1.1.40，着重讲述其序列化、反序列化实现，*后分析FastJSON为何如此“fast”的原因。

1. 序列化

所谓序列化，就是将java各种对象转化为json串。不多说，先上图。

%title插图%num

 序列化入口

平常我们经常用到的是JSON.toJSONString()这个静态方法来实现序列化。其实JSON是一个抽象类，该类实现了JSONAware（转为json串）和JSONStreamAware（将json串写入Appendable中）的接口，同时又是JSONArray（内部实现就是个List）和JSONObject（内部实现就是个Map）的父类。JSON.toJSONString()方法内部实现基本相同，为做某些特定配置，对外暴露的接口可能不同。该方法的实现实际托付给了JSONSerializer类。

序列化组合器

JSONSerializer类相当于一个序列化组合器，它将上层调用、序列化配置、具体类型序列化实现、序列化字符串拼接等功能组合在一起，方便外部统一调用。该类有几个重要的成员，SerializeConfig、SerializeWriter、各种Filter列表、DateFormat、SerialContext等，还有每次对各个具体对象序列化的ObjectSerializer（非JSONSerializer的成员变量）。下面就来挨个说明其各自功能。

1. SerializeConfig

SerializeConfig是全局唯一的，它继承自IdentityHashMap，IdentityHashMap是一个长度默认为1024的Hash桶，每个桶存放相同Hash的Entry（可看做链表节点，包含key、value、next指针、hash值）做成的单向链表，IdentityHashMap实现了HashMap的功能，但能避免HashMap并发时的死循环。

SerializeConfig的主要功能是配置并记录每种Java类型对应的序列化类（ObjectSerializer接口的实现类），比如Boolean.class使用BooleanCodec（看命名就知道该类将序列化和反序列化实现写到一起了）作为序列化实现类，float[].class使用FloatArraySerializer作为序列化实现类。这些序列化实现类，有的是FastJSON中默认实现的（比如Java基本类），有的是通过ASM框架生成的（比如用户自定义类），有的甚至是用户自定义的序列化类（比如Date类型框架默认实现是转为毫秒，应用需要转为秒）。当然，这就涉及到是使用ASM生成序列化类还是使用JavaBean的序列化类类序列化的问题，这里判断根据就是是否Android环境（环境变量”java.vm.name”为”dalvik”或”lemur”就是Android环境），但判断不仅这里一处，后续还有更具体的判断。

2. SerializeWriter

SerializeWriter继承自Java的Writer，其实就是个转为FastJSON而生的StringBuilder，完成高性能的字符串拼接。该类成员如下：

 

  • char buf[]

可理解为每次序列化后字符串的内存存放地址。

 

  • static ThreadLocal> bufLocal

每次序列化，都需要重新分配buf[]内存空间。而bufLocal就是每次序列化后bug[]的内存空间保留到ThreadLocal里，但其中的值清空，避免频繁的内存分配和gc。

 

  • int features

生成json字符串的特征配置，默认配置为：

<span>QuoteFieldNames | SkipTransientField | WriteEnumUsingToString | SortField</span>

表示含义为：双引号filedName and 忽略transientField and enum类型使用String写入 and 排序输出field。 支持的所有特征在SerializerFeature类中，用户可在调用时显示配置，也可通过JSONFiled或JSONType注入配置。

 

  • Writer

writer 用户指定将生成的json串直接写入某writer中，比如JSONWriter类。

举个例子吧，writeStringWithDoubleQuote()表示用字符串用双引号写入，看看如何拼接字符串的。

3. Filter列表

SerializeWriter中有很多Filter列表，可视为在生成json串的各阶段、各地方定制序列化，大致如下：

 

  • BeforeFilter ：序列化时在*前面添加内容
  • AfterFilter ：序列化时在*后面添加内容
  • PropertyFilter ：根据PropertyName和PropertyValue来判断是否序列化
  • ValueFilter ：修改Value
  • NameFilter ：修改key
  • PropertyPreFilter ：根据PropertyName判断是否序列化

4. DateFormat

指定日期格式。若不指定，FastJSON会自动识别如下日期格式：

 

  • ISO-8601日期格式
  • yyyy-MM-dd
  • yyyy-MM-dd HH:mm:ss
  • yyyy-MM-dd HH:mm:ss.SSS
  • 毫秒数值
  • 毫秒字符串
  • .Net Json日期格式
  • new Date()

5. SerialContext

序列化上下文，在引用或循环引用中使用，该值会放入references的Hash桶（IdentityHashMap）缓存。

6. ObjectSerializer  

ObjectSerializer只有一个接口方法，如下：

void write(JSONSerializer serializer,Objectobject,Object
    fieldName,Type fieldType);

可见，将JSONSerializer传入了ObjectSerializer中，而JSONSerializer有SerializeWriter成员，在每个具体ObjectSerializer实现中，直接使用SerializeWriter拼接字符串即可；Object即是待序列化的对象；fieldName则主要用于组合类引用时设置序列化上下文；而fieldType主要是为了泛型处理。

JSONSerializer中通过public ObjectSerializer getObjectWriter(Class clazz)函数获取类对应的序列化类（即实现ObjectSerializer接口的类），大致逻辑如下：

%title插图%num

整个过程是先获取已实现基础类对应的序列化类，再通过类加载器获取自定义的AutowiredObjectSerializer序列化类，*后获取通过createJavaBeanSerializer()创建的序列化类。通过该方法会获取两种序列化类，一种是直接的JavaBeanSerializer（根据类的get方法、public filed等JavaBean特征序列化），另一种是createASMSerializer（通过ASM框架生成的序列化字节码），优先使用第二种。选择JavaBeanSerializer的条件为：

 

  • 该clazz为非public类
  • 该clazz的类加载器在ASMClassLoader的外部，或者clazz就是 Serializable.class，或者clazz就是Object.class
  • JSONType的注解指明不适用ASM
  • createASMSerializer加载失败

结合前面的讨论，可以得出使用ASM的条件：非Android系统、非基础类、非自定义的AutowiredObjectSerializer、非以上所列的使用JavaBeanSerializer条件。

具体基础类的序列化方法、JavaBeanSerializer的序列化方法和ASM生成的序列化方法可以参见代码，这里就不做一一讲解了。

2. 反序列化

所谓反序列化，就是将json串转化为对应的java对象。还是先上图。

%title插图%num

同样是JSON类作为反序列化入口，实现了parse()、parseObject()、parseArray()等将json串转换为java对象的静态方法。这些方法的实现，实际托付给了DefaultJSONParser类。

DefaultJSONParser类相当于序列化的JSONSerializer类，是个功能组合器，它将上层调用、反序列化配置、反序列化实现、词法解析等功能组合在一起，相当于设计模式中的外观模式，供外部统一调用。同样，我们来分析该类的几个重要成员，看看他是如何实现纷繁的反序列化功能的。

1.  ParserConfig

同SerializeConfig，该类也是全局唯一的解析配置，其中的boolean asmEnable同样判断是否为Andriod环境。与SerializeConfig不同的是，配置类和对应反序列类的IdentityHashMap是该类的私有成员，构造函数的时候就将基础反序列化类加载进入IdentityHashMap中。

2.  JSONLexer 

JSONLexer是个接口类，定义了各种当前状态和操作接口。JSONLexerBase是对JSONLexer实现的抽象类，类似于序列化的SerializeWriter类，专门解析json字符串，并做了很多优化。实际使用的是JSONLexerBase的两个子类JSONScanner和JSONLexerBase，前者是对整个字符串的反序列化，后者是接Reader直接序列化。简析JSONLexerBase的某些成员：

 

  • int token

由于json串具有一定格式，字符串会根据某些特定的字符来自解释所表示的意义，那么这些特定的字符或所处位置的字符在FastJSON中就叫一个token，比如”(“，”{“，”[“，”,”，”:”，key，value等，这些都定义在JSONToken类中。

 

  • char[] sbuf

解析器通过扫描输入字符串，将匹配得到的*细粒度的key、value会放到sbuf中。

 

  • static ThreadLocal> SBUF_REF_LOCAL

上面sbuf的空间不释放，在下次需要的时候直接拿出来使用，从避免的内存的频繁分配和gc。

 

  • features

反序列化特性的配置，同序列化的feature是通过int的位或来实现其特性开启还是关闭的。默认配置是：AutoCloseSource | UseBigDecimal | AllowUnQuotedFieldNames | AllowSingleQuotes |AllowArbitraryCommas | AllowArbitraryCommas | SortFeidFastMatch |IgnoreNotMatch ，表示检查json串的完整性 and 转换数值使用BigDecimal and 允许接受不使用引号的filedName and 允许接受使用单引号的key和value and 允许接受连续多个”,”的json串 and 使用排序后的field做快速匹配 and 忽略不匹配的key/value对。当然，这些参数也是可以通过其他途径配置的。

 

  • hasSpecial

对转义符的处理，比如’\0’，’\’等。

词法解析器是基于预测的算法从左到右一次遍历的。由于json串具有自身的特点，比如为key的token后*有可能是”:”，”:”之后可能是value的token或为”{“的token或为”[“的token等等，从而可以根据前一个token预判下一个token的可能，进而得知每个token的含义。分辨出各个token后，就可以获取具体值了，比如scanString获取key值，scanFieldString根据fieldName获取fieldValue，scanTrue获取java的true等等。其中，一般会对key进行缓存，放入SymbolTable（类似于IdentityHashMap）中，猜想这样做的目的是：应用解析的json串一般key就那么多，每次生成开销太多，干脆缓存着，用的就是就来取，还是空间换时间的技巧。

3.  List< ExtraTypeProvider >和List< ExtraProcessor >

视为对其他类型的处理和其他自定义处理而留的口子，用户可以自己实现对应接口即可。

4.  DateFormat

同序列化的DateFormat，不多说了。

5.  ParseContext 和 List< ResolveTask >

ParseContext同序列化的SerialContext，为引用甚至循环引用做准备。

List< ResolveTask >当然就是处理这种多层次甚至多重引用记录的list了。

6.  SymbolTable

上面提到的key缓存。

7.  ObjectDeserializer

跟ObjectSerializer也是相似的。先根据fieldType获取已缓存的解析器，如果没有则根据fieldClass获取已缓存的解析器，否则根据注解的JSONType获取解析器，否则通过当前线程加载器加载的AutowiredObjectDeserializer查找解析器，否则判断是否为几种常用泛型（比如Collection、Map等），*后通过createJavaBeanDeserializer来创建对应的解析器。当然，这里又分为JavaBeanDeserializer和asmFactory.createJavaBeanDeserializer两种。使用asm的条件如下：

 

  • 非Android系统
  • 该类及其除Object之外的所有父类为是public的
  • 泛型参数非空
  • 非asmFactory加载器之外的加载器加载的类
  • 非接口类
  • 类的setter函数不大于200
  • 类有默认构造函数
  • 类不能含有仅有getter的filed
  • 类不能含有非public的field
  • 类不能含有非静态的成员类
  • 类本身不是非静态的成员类

使用ASM生成的反序列化器具有较高的反序列化性能，比如对排序的json串可按顺序匹配解析，从而减少读取的token数，但如上要求也是蛮严格的。综上，FastJSON反序列化也支持基础反序列化器、JavaBeanDeserializer反序列化器和ASM构造的反序列化器，这里也不做一一讲解了。

3. Why So Fast

FastJSON真的很快，读后受益匪浅。个人总结了下快的原因（不一定完整）：

1.  专业的心做专业的事

不论是序列化还是反序列化，FastJSON针对每种类型都有与之对应的序列化和反序列化方法，就针对这种类型来做，优化性能自然更具针对性。自编符合json的SerializeWriter和JSONLexer，就连ASM框架也给简化掉了，只保留所需部分。不得不叹其用心良苦。

2.  无处不在的缓存

空间换时间的想法为程序员屡试不爽，而作者将该方法用到任何细微之处：类对应的序列化器/反序列化器全部存起来，方便取用；解析的key存起来，表面重复内存分配等等。

3.  不厌其烦的重复代码

我不知道是否作者故意为之，程序中出现了很多类似的代码，比如特殊字符处理、不同函数对相同token的处理等。这样虽对于程序员寻求规整相违背，不过二进制代码却很喜欢，无形之中减少了许多函数调用。

4.  不走寻常路

对于JavaBean，可以通过发射实现序列化和反序列化（FastJSON已有实现），但默认使用的是ASM框架生成对应字节码。为了性能，无所不用其*。

5.  一点点改变有很大的差别

排序对输出仅是一点小小的改变，丝毫不影响json的使用，但却被作者用在了解析的快速匹配上，而不用挨个拎出key。

6.  从规律中找性能

上面也讲到，FastJSON读取token基于预测的。json串自身的规律性被作者逮个正着，预测下一个将出现的token处理比迷迷糊糊拿到一个token再分情况处理更快捷。

MySQL的四种事务隔离级别

本文实验的测试环境：Windows 10+cmd+MySQL5.6.36+InnoDB

一、事务的基本要素（ACID）

　　1、原子性（Atomicity）：事务开始后所有操作，要么全部做完，要么全部不做，不可能停滞在中间环节。事务执行过程中出错，会回滚到事务开始前的状态，所有的操作就像没有发生一样。也就是说事务是一个不可分割的整体，就像化学中学过的原子，是物质构成的基本单位。

　　 2、一致性（Consistency）：事务开始前和结束后，数据库的完整性约束没有被破坏 。比如A向B转账，不可能A扣了钱，B却没收到。

　　 3、隔离性（Isolation）：同一时间，只允许一个事务请求同一数据，不同的事务之间彼此没有任何干扰。比如A正在从一张银行卡中取钱，在A取钱的过程结束前，B不能向这张卡转账。

　　 4、持久性（Durability）：事务完成后，事务对数据库的所有更新将被保存到数据库，不能回滚。

 

二、事务的并发问题

　　1、脏读：事务A读取了事务B更新的数据，然后B回滚操作，那么A读取到的数据是脏数据

　　2、不可重复读：事务 A 多次读取同一数据，事务 B 在事务A多次读取的过程中，对数据作了更新并提交，导致事务A多次读取同一数据时，结果 不一致。

　　3、幻读：系统管理员A将数据库中所有学生的成绩从具体分数改为ABCDE等级，但是系统管理员B就在这个时候插入了一条具体分数的记录，当系统管理员A改结束后发现还有一条记录没有改过来，就好像发生了幻觉一样，这就叫幻读。

　　小结：不可重复读的和幻读很容易混淆，不可重复读侧重于修改，幻读侧重于新增或删除。解决不可重复读的问题只需锁住满足条件的行，解决幻读需要锁表

 

三、MySQL事务隔离级别

事务隔离级别 脏读 不可重复读 幻读
读未提交（read-uncommitted） 是 是 是
不可重复读（read-committed） 否 是 是
可重复读（repeatable-read） 否 否 是
串行化（serializable） 否 否 否

 

 

 

 

 

mysql默认的事务隔离级别为repeatable-read

%title插图%num

 

四、用例子说明各个隔离级别的情况

1、读未提交：

（1）打开一个客户端A，并设置当前事务模式为read uncommitted（未提交读），查询表account的初始值：

%title插图%num

（2）在客户端A的事务提交之前，打开另一个客户端B，更新表account：

%title插图%num

 

（3）这时，虽然客户端B的事务还没提交，但是客户端A就可以查询到B已经更新的数据：

%title插图%num

（4）一旦客户端B的事务因为某种原因回滚，所有的操作都将会被撤销，那客户端A查询到的数据其实就是脏数据：

%title插图%num

（5）在客户端A执行更新语句update account set balance = balance – 50 where id =1，lilei的balance没有变成350，居然是400，是不是很奇怪，数据不一致啊，如果你这么想就太天真 了，在应用程序中，我们会用400-50=350，并不知道其他会话回滚了，要想解决这个问题可以采用读已提交的隔离级别

%title插图%num

 

2、读已提交

（1）打开一个客户端A，并设置当前事务模式为read committed（未提交读），查询表account的所有记录：

%title插图%num

（2）在客户端A的事务提交之前，打开另一个客户端B，更新表account：

%title插图%num

（3）这时，客户端B的事务还没提交，客户端A不能查询到B已经更新的数据，解决了脏读问题：

%title插图%num

（4）客户端B的事务提交

%title插图%num

（5）客户端A执行与上一步相同的查询，结果 与上一步不一致，即产生了不可重复读的问题

%title插图%num

 

3、可重复读

（1）打开一个客户端A，并设置当前事务模式为repeatable read，查询表account的所有记录

%title插图%num

（2）在客户端A的事务提交之前，打开另一个客户端B，更新表account并提交

%title插图%num

（3）在客户端A查询表account的所有记录，与步骤（1）查询结果一致，没有出现不可重复读的问题

%title插图%num

（4）在客户端A，接着执行update balance = balance – 50 where id = 1，balance没有变成400-50=350，lilei的balance值用的是步骤（2）中的350来算的，所以是300，数据的一致性倒是没有被破坏。可重复读的隔离级别下使用了MVCC机制，select操作不会更新版本号，是快照读（历史版本）；insert、update和delete会更新版本号，是当前读（当前版本）。

%title插图%num

（5）重新打开客户端B，插入一条新数据后提交

%title插图%num

（6）在客户端A查询表account的所有记录，没有 查出 新增数据，所以没有出现幻读

%title插图%num

 

4.串行化

（1）打开一个客户端A，并设置当前事务模式为serializable，查询表account的初始值：

复制代码

mysql> set session transaction isolation level serializable;
Query OK, 0 rows affected (0.00 sec)

mysql> start transaction;
Query OK, 0 rows affected (0.00 sec)

mysql> select * from account;
+------+--------+---------+
| id   | name   | balance |
+------+--------+---------+
|    1 | lilei  |   10000 |
|    2 | hanmei |   10000 |
|    3 | lucy   |   10000 |
|    4 | lily   |   10000 |
+------+--------+---------+
4 rows in set (0.00 sec)

复制代码

（2）打开一个客户端B，并设置当前事务模式为serializable，插入一条记录报错，表被锁了插入失败，mysql中事务隔离级别为serializable时会锁表，因此不会出现幻读的情况，这种隔离级别并发性*低，开发中很少会用到。

复制代码

mysql> set session transaction isolation level serializable;
Query OK, 0 rows affected (0.00 sec)

mysql> start transaction;
Query OK, 0 rows affected (0.00 sec)

mysql> insert into account values(5,'tom',0);
ERROR 1205 (HY000): Lock wait timeout exceeded; try restarting transaction

复制代码

 

补充：

　　1、事务隔离级别为读提交时，写数据只会锁住相应的行

　　2、事务隔离级别为可重复读时，如果检索条件有索引（包括主键索引）的时候，默认加锁方式是next-key 锁；如果检索条件没有索引，更新数据时会锁住整张表。一个间隙被事务加了锁，其他事务是不能在这个间隙插入记录的，这样可以防止幻读。

　　3、事务隔离级别为串行化时，读写数据都会锁住整张表

　　 4、隔离级别越高，越能保证数据的完整性和一致性，但是对并发性能的影响也越大。

　　 5、MYSQL MVCC实现机制参考链接：https://blog.csdn.net/whoamiyang/article/details/51901888

　　 6、关于next-key 锁可以参考链接：https://blog.csdn.net/bigtree_3721/article/details/73731377

240. 搜索二维矩阵 II（JS实现）

240. 搜索二维矩阵 II（JS实现）

1 题目
编写一个高效的算法来搜索 m x n 矩阵 matrix 中的一个目标值 target。该矩阵具有以下特性：
每行的元素从左到右升序排列。
每列的元素从上到下升序排列。
示例:
现有矩阵 matrix 如下：
[
[1, 4, 7, 11, 15],
[2, 5, 8, 12, 19],
[3, 6, 9, 16, 22],
[10, 13, 14, 17, 24],
[18, 21, 23, 26, 30]
]
给定 target = 5，返回 true。
给定 target = 20，返回 false。

链接：https://leetcode-cn.com/problems/search-a-2d-matrix-ii

2 思路
**我是用二分法做的，并不是*优解，题解中有一种双指针法很巧妙
首先，我们初始化一个指向矩阵左下角的 (row，col)(row，col) 指针。然后，直到找到目标并返回 true（或者指针指向矩阵维度之外的 (row，col)(row，col) 为止，我们执行以下操作：如果当前指向的值大于目标值，则可以 “向上” 移动一行。 否则，如果当前指向的值小于目标值，则可以移动一列。不难理解为什么这样做永远不会删减正确的答案；因为行是从左到右排序的，所以我们知道当前值右侧的每个值都较大。 因此，如果当前值已经大于目标值，我们知道它右边的每个值会比较大。也可以对列进行非常类似的论证，因此这种搜索方式将始终在矩阵中找到目标（如果存在）
**

3代码
/**
* @param {number[][]} matrix
* @param {number} target
* @return {boolean}
*/
var searchMatrix = function(matrix, target) {
let rows = matrix.length;
if (rows === 0) return false;
let cols = matrix[0].length;
if (cols === 0) return false;

if (target < matrix[0][0] || target > matrix[rows-1][cols-1]) return false;

let low = 0;
let high = rows – 1;

while(low < high) {
let mid = Math.floor((low + high) / 2);

if (matrix[mid][0] > target) {
high = mid – 1;
} else if (matrix[mid][cols-1] < target) {
low = mid + 1;
} else {
break;
}
}

let currentRow = low;

while(currentRow <= high) {
let low1 = 0;
let high1 = cols – 1;

while(low1 <= high1) {
let mid = Math.floor((low1 + high1) / 2);

if (matrix[currentRow][mid] > target) {
high1 = mid – 1;
} else if (matrix[currentRow][mid] < target) {
low1 = mid + 1;
} else {
return true;
}
}

currentRow++;
}

return false;
};

spring注解-@Transactional事务几点注意

这里面有几点需要大家留意：
A. 一个功能是否要事务，必须纳入设计、编码考虑。不能仅仅完成了基本功能就ok。
B. 如果加了事务，必须做好开发环境测试（测试环境也尽量触发异常、测试回滚），确保事务生效。
C. 以下列了事务使用过程的注意事项，请大家留意。
1. 不要在接口上声明@Transactional ，而要在具体类的方法上使用 @Transactional 注解，否则注解可能无效。
2.不要图省事，将@Transactional放置在类级的声明中，放在类声明，会使得所有方法都有事务。故@Transactional应该放在方法级别，不需要使用事务的方法，就不要放置事务，比如查询方法。否则对性能是有影响的。
3.使用了@Transactional的方法，对同一个类里面的方法调用， @Transactional无效。比如有一个类Test，它的一个方法A，A再调用Test本类的方法B（不管B是否public还是private），但A没有声明注解事务，而B有。则外部调用A之后，B的事务是不会起作用的。（经常在这里出错）
4.使用了@Transactional的方法，只能是public，@Transactional注解的方法都是被外部其他类调用才有效，故只能是public。道理和上面的有关联。故在 protected、private 或者 package-visible 的方法上使用 @Transactional 注解，它也不会报错，但事务无效。
5.经过在ICORE-CLAIM中测试，效果如下：
A.抛出受查异常XXXException，事务会回滚。
B.抛出运行时异常NullPointerException，事务会回滚。
C.Quartz中，execute直接调用加了@Transactional方法，可以回滚；间接调用，不会回滚。（即上文3点提到的）
D.异步任务中，execute直接调用加了@Transactional方法，可以回滚；间接调用，不会回滚。（即上文3点提到的）
E.在action中加上@Transactional，不会回滚。切记不要在action中加上事务。
F.在service中加上@Transactional，如果是action直接调该方法，会回滚，如果是间接调，不会回滚。（即上文3提到的）
G.在service中的private加上@Transactional，事务不会回滚。

spring事务@Transactional在同一个类中的方法调用不生效

spring提供了非常强大的事务管理机制，之前一直以为只要在想要加注解的方法上加个@Transactional注解就万事大吉了

%title插图%num

但是今天发现这样做在某些情况下会有bug，导致事务无法生效。

当这个方法被同一个类调用的时候，spring无法将这个方法加到事务管理中。

我们来看一下生效时候和不生效时候调用堆栈日志的对比。

%title插图%num

通过对比两个调用堆栈可以看出，spring的@Transactional事务生效的一个前提是进行方法调用前经过拦截器TransactionInterceptor，也就是说只有通过TransactionInterceptor拦截器的方法才会被加入到spring事务管理中，查看spring源码可以看到，在AdvisedSupport.getInterceptorsAndDynamicInterceptionAdvice方法中会从调用方法中获取@Transactional注解，如果有该注解，则启用事务，否则不启用。

%title插图%num

这个方法是通过spring的AOP类CglibAopProxy的内部类DynamicAdvisedInterceptor调用的，而DynamicAdvisedInterceptor继承了MethodInterceptor，用于拦截方法调用，并从中获取调用链。

如果是在同一个类中的方法调用，则不会被方法拦截器拦截到，因此事务不会起作用，必须将方法放入另一个类，并且该类通过spring注入。

为运算表达式设计优先级（JS实现）

为运算表达式设计优先级（JS实现）

1 题目
给定一个含有数字和运算符的字符串，为表达式添加括号，改变其运算优先级以求出不同的结果。你需要给出所有可能的组合的结果。有效的运算符号包含 +, – 以及 * 。
示例 1:
输入: “2-1-1”
输出: [0, 2]
解释:
((2-1)-1) = 0
(2-(1-1)) = 2
示例 2:
输入: “23-45”
输出: [-34, -14, -10, -10, 10]
解释:
(2*(3-(45))) = -34
((23)-(45)) = -14
((2(3-4))5) = -10
(2((3-4)5)) = -10
(((23)-4)*5) = 10

链接：https://leetcode-cn.com/problems/different-ways-to-add-parentheses

2 思路
这道题主要用分治的思想来做，对于一个表达式，我们可以以其中一个运算符为分界，将其划分为两个子表达式，原表达式的计算结果就是这两个子表达式计算结果再进行运算而得到的，而这子表达式又可以进一步分割为两个表达式，如此递归下去，直至表达式不可分割，也就是只剩一个数字，所有的分割方法就是*后的答案

3代码
/**
* @param {string} input
* @return {number[]}
*/
var diffWaysToCompute = function(input) {
if (input.length === 0) return [];
let num = parseInt(input);
if (num == input) return [num]; //如果是数字，则不可分割

let result = [];
for (let i=1; i<input.length-1; i++) {
if (parseInt(input[i]) == input[i]) continue;
let nums1 = diffWaysToCompute(input.slice(0,i)); //以第i个运算字符，进行分割
let nums2 = diffWaysToCompute(input.slice(i+1));
let res;
for (let num1 of nums1) { //将所有子表达式的可能结果进行运算
for (let num2 of nums2) {
if (input[i] === ‘+’) {
res = num1 + num2;
} else if (input[i] === ‘-‘) {
res = num1 – num2;
} else {
res = num1 * num2;
}
result.push(res);
}
}
}

return result;
};