mmap 基础概念

mmap 是一种内存映射文件的方法，即将一个文件映射到进程的地址空间，实现文件磁盘地址和一段进程虚拟地址的映射。实现这样的映射关系后，进程就可以采用指针的方式读写操作这一段内存，而系统会自动回写脏页到对应的文件磁盘上，即完成了对文件的操作而不必再调用 read,write 等系统调用函数。相反，内核空间对这段区域的修改也直接反映用户空间，从而可以实现不同进程间的文件共享。

操作系统提供了这么一系列 mmap 的配套函数

1
2
3

void *mmap(void *start, size_t length, int prot, int flags, int fd, off_t offset);
int munmap( void * addr, size_t len);
int msync( void *addr, size_t len, int flags);

前言

人总是这样，年少时，怨恨自己年少，年迈时，怨恨自己年迈，就连参加一场比赛，都会纠结，工作太忙怎么办，周末休息怎么办，成年人的任性往往就在那一瞬间，我只是单纯地想经历一场酣畅的性能挑战赛。所以，云原生挑战赛，我来了，Kirito 带着他的公众号来了。

读完寥寥数百多字的赛题描述，四分之一炷香之后一个灵感出现在脑海中，本以为这个灵感是开篇，没想到却是终章。临近结束，测试出了缓存命中率更高的方案，但评测已经没有了日志，在茫茫的方案之中，我错过了最大的那一颗麦穗，但在一个月不长不短的竞赛中，我挑选到了一颗不错的麦穗，从此只有眼前路，没有身后身，最终侥幸跑出了内部赛第一的成绩。

传统存储引擎类型的比赛，主要是围绕着两种存储介质：SSD 和 DRAM，不知道这俩有没有熬过七年之痒，Intel 就已经引入了第三类存储介质：AEP（PMem 的一种实现）。AEP 的出现，让原本各司其职的 SSD 和 DRAM 关系变得若即若离起来，它既可以当做 DRAM 用，也可以当做 SSD 用。蕴含在赛题中的”冷热存储“这一关键词，为后续风起云涌的赛程埋下了伏笔，同时给了 AEP 一个名分。

AEP 这种存储介质不是第一次出现在我眼前，在 ADB 比赛中就遇到过它，此次比赛开始时，脑子里面对它仅存的印象便是”快”。这个快是以 SSD 为参照物，无论是读还是写，都高出传统 SSD 1~n 个数量级。但更多的认知，只能用 SSD 来类比，AEP 特性的理解和使用方法，无疑是这次的决胜点之一。

曾经的我喜欢问，现在的我喜欢试。一副键盘，一个深夜，我窥探到了 AEP 的奥秘，多线程读写必不可少，读取速度和写入速度近似 DRAM，但细究之下写比读慢，从整体吞吐来看，DRAM 的读写性能略优于 AEP，但 DRAM 和 AEP 的读写都比 SSD 快得多的多。我的麦穗也有了初步的模样：第一优先级是降低 SSD 命中率，在此基础上，提高 DRAM 命中率，AEP 起到平衡的效果，初期不用特别顾忌 AEP 和 DRAM 的命中比例。

在很多追求性能的程序挑战赛中，经常会遇到一个操作：将 String 转换成 Integer/Long。如果你没有开发过高并发的系统，或者没有参加过任何性能挑战赛，可能会有这样的疑问：这有啥好讲究的，Integer.valueOf/Long.valueOf 又不是不能用。实际上，很多内置的转换工具类只满足了功能性的需求，在高并发场景下，可能会是热点方法，成为系统性能的瓶颈。

文章开头，我先做一下说明，本文的测试结论出自：https://kholdstare.github.io/technical/2020/05/26/faster-integer-parsing.html 。测试代码基于 C++，我会在翻译原文的同时，添加了部分自己的理解，以协助读者更好地理解其中的细节。

前言

之前在分享《海量无序数据寻找第 K 大的数》这篇文章时，就已经提到过我参加了阿里云举办的《第三届数据库大赛创新上云性能挑战赛–高性能分析型查询引擎赛道》，传送门：https://tianchi.aliyun.com/competition/entrance/531895/introduction。 截止到 8 月 20 日，终于结束了漫长的赛程。作为阿里云员工的我，按照赛题规定，只能参加初赛，不能参加复赛，出于不影响比赛的目的，终于等到了比赛完全结束，才动笔写下了这篇参赛总结。

照例先说成绩，这里贴一下排行榜，总共有 1446 只队伍，可以看到不少学生和其他公司的员工都参赛了。

我的成绩是第 14 名（普哥忙于 KPI，没有能带飞我，diss 一下嘿嘿），内部排名也是进入了前五，虽然被剥夺了参加复赛的资格，但是也给了内部的奖励作为补偿，奖品是啥呢？

前言

最近在参加阿里云举办的《第三届数据库大赛创新上云性能挑战赛–高性能分析型查询引擎赛道》，传送门：https://tianchi.aliyun.com/competition/entrance/531895/introduction

好久没有打比赛了，也是突然来了兴致，参加性能挑战赛总有一种自己还年轻的感觉。因为比赛还没有结束，所以赛题解析还不方便这时候就写出来，但是其中一个优化点，倒是可以拿出来跟大家分享下。

简单抽象一下问题，便是今天的主题：在一个百万级无序的 long 数组中，寻找第 K 大的数值。要求当然是越快找到越好。

1 前言

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

1 前言

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

维持了 20 天的复赛终于告一段落了，国际惯例先说结果，复赛结果不太理想，一度从第 10 名掉到了最后的第 36 名，主要是写入的优化卡了 5 天，一直没有进展，最终排名也是定格在了排行榜的第二页。痛定思痛，这篇文章将自己复赛中学习的知识，成功的优化，未成功的优化都罗列一下。

天池中间件大赛的初赛在今早终于正式结束了，公众号停更了一个月，主要原因就是博主的空余时间几乎全花在这个比赛上，第一赛季结束，做下参赛总结，总的来说，收获不小。