1 前言

回顾第一次参加性能挑战赛 – 第四届阿里中间件性能挑战赛，那时候真的是什么都不会，只有一腔热情，借着比赛学会了 Netty、学会了文件 IO 的最佳实践，到了这次华为云举办的 TaurusDB 性能挑战赛，已经是第三次参加比赛了，同时也是最“坎坷”的一次比赛。经过我和某位不愿意透露姓名的 96 年小迷妹的不懈努力，最终跑分排名为第 3 名。

引子

记得那是一个风和日丽的周末，太阳红彤彤，花儿五颜六色，96 年的普哥微信找到我，描述了一个诡异的线上问题：线上程序使用了 NIO FileChannel 的 堆内内存（HeapByteBuffer）作为缓冲区，读写文件，逻辑可以说相当简单，但根据监控，却发现堆外内存（DirectByteBuffer）飙升，导致了 OutOfMemeory 的异常。

由这个线上问题，引出了这篇文章的主题，主要包括：FileChannel 源码分析，堆外内存监控，堆外内存回收。

1 前言

国际惯例，先报成绩，熬了无数个夜晚，最后依旧被绝杀出了第一页，最终排名第 21 名。前十名的成绩分布为 413.69~416.94，我最终的耗时是 422.43。成绩虽然不是特别亮眼，但与众多参赛选手使用 C++ 作为参赛语言不同，我使用的是 Java，一方面是我 C++ 的能力早已荒废，另一方面是我想验证一下使用 Java 编写存储引擎是否与 C++ 差距巨大 (当然，主要还是前者 QAQ)。所以在本文中，我除了介绍整体的架构之外，还会着重笔墨来探讨 Java 编写存储类型应用的一些最佳实践，文末会给出 github 的开源地址。

乐观锁的概念就不再赘述了，不了解的朋友请自行百度谷歌之，今天主要说的是在项目中如何使用乐观锁，做成一个小 demo。

持久层使用 jpa 时，默认提供了一个注解 @Version 先看看源码怎么描述这个注解的

1
2
3
4

@Target({METHOD, FIELD})
@Retention(RUNTIME)
public @interface Version {
}

简单来说就是用一个 version 字段来充当乐观锁的作用。
先来设计实体类

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

/**
 * Created by xujingfeng on 2017/1/30.
 */
@Entity
@Table(name = "t_student")
public class Student {

    @Id
    @GenericGenerator(name = "PKUUID", strategy = "uuid2")
    @GeneratedValue(generator = "PKUUID")
    @Column(length = 36)
    private String id;

    @Version
    private int version;

    private String name;

    //getter()...
    //setter()...
}