1.记一次源码追踪分析，源码从Java到JNI，源码再到JVM的源码C++：fileChannel.map()为什么快；源码分析map方法，put方法
2.c++网络编程：Boost.asio源码剖析
3.Protocol Buffer详解（一）

记一次源码追踪分析，源码从Java到JNI，源码再到JVM的源码glusterfs源码分析C++：fileChannel.map()为什么快；源码分析map方法，put方法

       前言

       在系统IO相关的源码系统调用有read/write，mmap，源码sendfile等这些。源码

       其中read/write是源码普通的读写，每次都需要将buffer从用户空间拷贝到内核空间；

       而mmap使用的源码是内存映射，会将磁盘文件对应的源码页映射（拷贝）到内核空间的page cache，并记录到用户进程的源码页表中，使得用户空间也可以像操作用户空间一样操作该文件的源码映射，最后再由操作系统来讲该映射（脏页）回写到磁盘；

       sendfile则使用的源码是零拷贝技术，在mmap的基础上，当发送数据的时候只拷贝fd和offset等元数据信息，而将数据主体直接拷贝至protocol buffer，实现了内核数据零冗余的零拷贝技术

       本文地址：/post//

问题/目的问题1Java中哪些API使用到了mmap问题2怎么知道该API使用到了mmap，如何追踪程序的系统调用目的1源码中分析验证，从Java到JNI，再到C++：fileChannel.map()使用的是系统调用mmap目的2源码验证分析：调用mmapedByteBuffer.put(Byte[])时JVM在搞些什么？mmap比普通的read/write快在哪？揭晓答案1mmap在Java NIO中的体现/使用

       看一个例子

// 1GBpublic static final int _GB = 1**;File file = new File("filename");FileChannel fileChannel = new RandomAccessFile(file, "rw").getChannel();MappedByteBuffer mmapedByteBuffer = fileChannel.map(FileChannel.MapMode.READ_WRITE, 0, _GB);for (int i = 0; i < _GB; i++) { count++;mmapedByteBuffer.put((byte)0);}

       其中fileChannel.map()底层使用的就是系统调用mmap，函数签名为： public abstract MappedByteBuffer map(MapMode mode,long position, long size)throws IOException

答案2程序执行的系统调用追踪/** * @author Tptogiar * @description * @date /5/ - : */public class TestMappedByteBuffer{ public static final int _4kb = 4*;public static final int _GB= 1**;public static void main(String[] args) throws IOException, InterruptedException { // 为了方便在日志中找到本段代码的开始位置和结束位置，这里利用文件io来打开始标记FileInputStream startInput = null;try { startInput = new FileInputStream("start1.txt");startInput.read();} catch (IOException e) { e.printStackTrace();}File file = new File("filename");FileChannel fileChannel = new RandomAccessFile(file, "rw").getChannel();MappedByteBuffer map = fileChannel.map(FileChannel.MapMode.READ_WRITE, 0, _GB); //我们想分析的语句问题2for (int i = 0; i < _GB; i++) { map.put((byte)0); // 下文中需要分析的语句目的2}// 打结束标记FileInputStream endInput = null;try { endInput = new FileInputStream("end.txt");endInput.read();} catch (IOException e) { e.printStackTrace();}}}

       把上面这段代码编译后把“.class”文件拉到linux执行，并用linux上的strace工具记录其系统调用日志，拿到日志文件我们可以在日志中看到以下信息（关于怎么拿到日志可以参照我的博文：无（代写））：

       注：日志有多行，这里只选取我们关注的

// ...// 看到了我们打的开始标志openat(AT_FDCWD, "start1.txt", O_RDONLY) = -1 ENOENT (No such file or directory)// ... // 打开文件，文件描述符fd为6openat(AT_FDCWD, "filename", O_RDWR|O_CREAT, ) = 6// 判断文件状态fstat(6, { st_mode=S_IFREG|, st_size=, ...}) = 0// ... // 判断文件状态fstat(6, { st_mode=S_IFREG|, st_size=, ...}) = 0// 进行内存映射mmap(NULL, , PROT_READ|PROT_WRITE, MAP_SHARED, 6, 0) = 0x7f2fd6cd// ...// 程序退出exit(0)// 看到了我们打的结束标志openat(AT_FDCWD, "end.txt", O_RDONLY) = -1 ENOENT (No such file or directory)

       在上面程序的系统调用日志中我们确实看到了我们打的开始标志，结束标志。远景源码在开始标志和结束标志之间我们看到了我们的文件"filename"确实被打开了，文件描述符fd = 6；在打开文件后紧接着又执行了系统调用mmap，这一点我们Java代码一致，这样，我们就验证了我们答案1中的结论，可以开始我们的下文了

源码追踪分析，从Java到JNI，再到JVM的C++目的1寻源之旅：fileChannel.map()

       我们知道我们执行Java代码fileChannel.map()确实会在底层调用系统调用，那怎么在源码中得到验证呢？怎么落脚于源码进行分析呢？下面开始我们的寻源之旅

       FileChannelImpl.map() 注：由于代码较长，这里代码中略去了一些我们不关注的,比如异常捕获等

public MappedByteBuffer map(MapMode mode, long position, long size)throws IOException{ // ...try { // ...synchronized (positionLock) { // ...long mapPosition = position - pagePosition;mapSize = size + pagePosition;try { // ！我们要找的语句就在这！addr = map0(imode, mapPosition, mapSize);} catch (OutOfMemoryError x) { // 如果内存不足，先尝试进行GCSystem.gc();try { Thread.sleep();} catch (InterruptedException y) { Thread.currentThread().interrupt();}try { // 再次试着mmapaddr = map0(imode, mapPosition, mapSize);} catch (OutOfMemoryError y) { // After a second OOME, failthrow new IOException("Map failed", y);}}} // ...} finally { // ...}}

       上面函数源码中真正执行mmap的语句是在addr = map0(imode, mapPosition, mapSize),于是我们寻着这里继续追踪

       FileChannelImpl.map0()

// Creates a new mappingprivate native long map0(int prot, long position, long length)throws IOException;

       可以看到，该方法是一个native方法，所以后面的源码我们需要到这个FileChannelImpl.class对应的fileChannelImpl.c中去看，所以我们需要去找到JDK的源码

       在JDK源码中我们找到fileChannelImpl.c文件

       fileChannelImpl.c 根据JNI的对应规则，我们找到该文件内对应的Java_sun_nio_ch_FileChannelImpl_map0方法，其源码如下：

JNIEXPORT jlong JNICALLJava_sun_nio_ch_FileChannelImpl_map0(JNIEnv *env, jobject this, jint prot, jlong off, jlong len){ void *mapAddress = 0;jobject fdo = (*env)->GetObjectField(env, this, chan_fd);jint fd = fdval(env, fdo);int protections = 0;int flags = 0;if (prot == sun_nio_ch_FileChannelImpl_MAP_RO) { protections = PROT_READ;flags = MAP_SHARED;} else if (prot == sun_nio_ch_FileChannelImpl_MAP_RW) { protections = PROT_WRITE | PROT_READ;flags = MAP_SHARED;} else if (prot == sun_nio_ch_FileChannelImpl_MAP_PV) { protections =PROT_WRITE | PROT_READ;flags = MAP_PRIVATE;}// ！我们要找的语句就在这里！mapAddress = mmap(0,/* Let OS decide location */len,/* Number of bytes to map */protections,/* File permissions */flags,/* Changes are shared */fd, /* File descriptor of mapped file */off); /* Offset into file */if (mapAddress == MAP_FAILED) { if (errno == ENOMEM) { JNU_ThrowOutOfMemoryError(env, "Map failed");return IOS_THROWN;}return handle(env, -1, "Map failed");}return ((jlong) (unsigned long) mapAddress);}

       我们要找的语句就上面代码中的mapAddress = mmap(0,len,protections,flags,fd,off),至于为什么不是直接的mmap，而是mmap，是因为这里的mmap是一个宏，在文件上方有其定义，如下：

#define mmap mmap

       至此，我们就在源码中得到验证了我们问题2中的结论：fileChannelImpl.map()底层使用的是mmap系统调用

目的2寻源之旅：mmapedByteBuffer.put(Byte[ ])

       接着我们来看看当我们调用mmapedByteBuffer.put(Byte[])JVM底层在搞些什么动作

       MappedByteBuffer ?首先我们得知道，当我们执行MappedByteBuffer map = fileChannel.map(FileChannel.MapMode.READ_WRITE, 0, _GB)时，实际返回的对象是DirectByteBuffer类的实例，因为MappedByteBuffer为抽象类，nginxupstream源码且只有DirectByteBuffer继承了它，看下面两图就明白了

       DirectByteBuffer 于是我们找到DirectByteBuffer内的put(Byte[ ])方法

public ByteBuffer put(byte x) { unsafe.putByte(ix(nextPutIndex()), ((x)));return this;}

       可以看到该方法内实际是调用Unsafe类内的putByte方法来实现功能的，所以我们还得去看Unsafe类

       Unsafe.class

public native voidputByte(long address, byte x);

       该方法在Unsafe内是一个native方法，所以所以我们还得去看unsafe.cpp文件内对应的实现

       unsafe.cpp

       在JDK源码中，我们找到unsafe.cpp

       在这份源码内，没有使用JNI内普通加前缀的方法来形成对应关系

       不过我们还是能顺着源码的蛛丝轨迹找到我们要找的方法

       注意到源码中有这样的注册机制，所以我们可以知道我们要找的代码就是上图中标注的代码

       顺藤摸瓜，我们就找到了该方法的定义

UNSAFE_ENTRY(void, Unsafe_SetNative##Type(JNIEnv *env, jobject unsafe, jlong addr, java_type x)) \UnsafeWrapper("Unsafe_SetNative"#Type); \JavaThread* t = JavaThread::current(); \t->set_doing_unsafe_access(true); \void* p = addr_from_java(addr); \*(volatile native_type*)p = x; \t->set_doing_unsafe_access(false); \UNSAFE_END \

       该方法内主要的逻辑语句就是以下两句：

/** * @author Tptogiar * @description * @date /5/ - : */public class TestMappedByteBuffer{ public static final int _4kb = 4*;public static final int _GB= 1**;public static void main(String[] args) throws IOException, InterruptedException { // 为了方便在日志中找到本段代码的开始位置和结束位置，这里利用文件io来打开始标记FileInputStream startInput = null;try { startInput = new FileInputStream("start1.txt");startInput.read();} catch (IOException e) { e.printStackTrace();}File file = new File("filename");FileChannel fileChannel = new RandomAccessFile(file, "rw").getChannel();MappedByteBuffer map = fileChannel.map(FileChannel.MapMode.READ_WRITE, 0, _GB); //我们想分析的语句问题2for (int i = 0; i < _GB; i++) { map.put((byte)0); // 下文中需要分析的语句目的2}// 打结束标记FileInputStream endInput = null;try { endInput = new FileInputStream("end.txt");endInput.read();} catch (IOException e) { e.printStackTrace();}}}0

       至此，我们就知道：其实我们调用mmapedByteBuffer.put(Byte[ ])时，JVM底层并不需要涉及到系统调用（这里也可以用strace工具追踪从而得到验证）。也就是说通过mmap映射的空间在内核空间和用户空间是共享的，我们在用户空间只需要像平时使用用户空间那样就行了————获取地址，设置值，而不涉及用户态，内核态的切换

总结

       fileChannelImpl.map()底层用调用系统函数mmap

       fileChannelImpl.map()返回的其实不是MappedByteBuffer类对象，而是DirectByteBuffer类对象

       在linux上可以通过strace来追踪系统调用

       JNI中“.class”文件内方法与“.cpp”文件内函数的对应关系不止是前缀对应的方法，还可以是注册的方式，这一点的追寻代码的时候有很大帮助

       directByteBuffer.put()方法底层并没有涉及系统调用，也就不需要涉及切态的性能开销(其底层知识执行获取地址，设置值的操作)，所以mmap的性能就比普通读写read/write好

       ...

原文：/post/

c++网络编程：Boost.asio源码剖析

       Boost库是一个可移植、提供源代码的C++库，作为标准库的后备，是C++标准化进程的开发引擎之一。Boost库由C++标准委员会库工作组成员发起，其中有些内容有望成为下一代C++标准库内容。在C++社区中影响甚大，sys源码是不折不扣的“准”标准库。

       boost.asio是Boost库中非常著名的I/O组件，是用于网络和低层IO编程的跨平台C++库，为开发者提供了C++环境下稳定的异步模型。其在性能、移植性、扩展性等方面均为人称道，甚至被很多业内人士称为“网络神器”。asio是目前唯一有希望进入C++标准库以弥补标准库在网络方面的缺失的C++网络库，因此对asio的学习在某种意义上可以说是学习C++网络编程的必修课。

       本文从源码角度出发，深入浅出地剖析asio的架构和设计理念，将asio的一切秘密呈现在读者眼前。适合已有较完善的C++基础知识、具备一定程度的泛型技术和面向对象技术、并对boost.asio有一定的了解的读者。

       asio的核心架构由三大组件构成：io_object、services服务和"Asio核心组件"，其中io_object是I/O对象的集合，包含socket、deadline_timer等对象；services服务是逻辑功能的实现者，包含deadline_timer_service、win_iocp_socket_service等服务；"Asio核心组件"即io_service，通过关联类service_registry管理服务，由io_object提供接口。

       io_service的真正逻辑实现封装在内部桥接的类io_service_impl中，io_service_impl继承于service_base，在io_service初始化时被创建并由io_service持有其引用。midishow源码asio中包含多个服务，如strand_service、deadline_timer_service、stream_socket_service等，以及对应的I/O对象如io_service::strand、basic_deadline_timer等。

       asio中还包含Protocol和InternetProtocol概念，用于定义通信协议和网络通信协议。此外，还引入了泛型概念如ConstBuffer、ConstBufferSequence、MutableBuffer、MutableBufferSequence、Stream、AsyncReadStream、AsyncWriteStream、SyncReadStream和SyncWriteStream等，使得asio在设计上更加灵活和高效。

       泛型与面向对象的完美结合使得asio在设计上既具有面向对象的封装性和可扩展性，又具备泛型编程的灵活性和高效性。通过Service Concept和CSU（Core-Service-User）架构，asio实现了用户友好的接口设计，使得开发者能够以简单而统一的方式使用asio提供的功能，无需自行处理复杂的泛型组件组装工作。

Protocol Buffer详解（一）

       Protocol Buffer是一种支持多平台、多语言、可扩展的数据序列化机制，与XML相比，protobuf体积更小、速度更快、使用更简单，支持自定义数据结构。通过protobu编译器，可以生成特定语言的源代码，如C++、Java、Python，protoBuf对主流编程语言都提供了支持，使得序列化和反序列化变得非常方便。

       一、Message定义

       这里给出一个简单的例子，是一个搜索请求的message格式。

       上述例子中fields的种类都是数值型的（string和int），当然也可以指定更加复杂的fields，比如枚举类型enum，或者是嵌套的message类型。

       1、分配field编号

       上述例子中每个field都被分配了一个编号，这个编号是该field的唯一标识。需要注意的是，标识1-在编码时只占用一个字节，-占用两个字节，因此为了进一步优化程序，对于经常出现的element，建议使用1-作为其唯一标识；对于不经常使用的element，建议使用-。编号的范围是1-2^（-是系统预留的，不要使用）。

       2、field类型

       message中的field类型包含以下两种（proto3）：

       （1）singular

       （2）repeated：该类型的field可以在message中重复使用（类似于数组），它们的顺序会被保存，通过索引进行检索，数值类型的repeated默认使用packed编码方式。

       3、多message结构

       在一个proto文件中可以定义多个protobuf。

       4、reserved field类型

       在开发过程中可能会涉及到对proto文件中message各个fields的修改，可能是更新、删除某个field及其表示，这样可能会导致调用的服务失败。其中一个防止这种问题的方式是，确保你要删除的field的标识（或是名字）是reserved，具体protobuf的编译器会决定未来这个field表示能否被使用。

       5、编译结果

       对于C++开发者来说，使用protoc编译一个proto文件之后，会生成pb.h和pb.cc两个文件。

       二、数值类型

       具体proto类型对应生成类中的类型可以参考官方文档。

       三、默认值

       对于string和byte类型，默认值为空；对于bool类型，默认值是false；对于数值类型，默认值是0；对于枚举类型，默认值是第一个枚举值，默认为0；对于message类型，默认值由编程语言决定；对于repeated field，默认值为空。

       四、枚举类型

       当采用枚举类型的之后，枚举中的值都是预先定义好的，对于上述例子，我们可以再额外增加一个枚举类型corpus，具体如下。

       通常枚举类型的第一个值初始化为0，而且在message中使用枚举类型，必须要给定一个为0的值，而且这个为0的值应该为第一个元素。

       也可以给不同的元素以相同的alias，但是需要指定option allow_alias = true;具体如下。

       除此之外枚举类型不仅可以定义在message内部，也可以定义在message外部，而且在不同message中可以重用enum。

       在更改枚举类型field时，为保证系统运行正常，同样可以指定reserved数字标识和命名。

       五、使用其他message类型

       1、同文件引用

       具体如下：

       2、不同文件引用

       引用其他proto文件中定义好的message类型，具体如下。

       有时我们会对引用的proto文件进行更改，比如将其内容移动到另外一个地方，这样我们就需要对调用方import路径进行更改，当调用方非常多的时候，这种方法是非常低效的，protobuf提供一种机制，我们可以在原有位置提供一个新位置proto文件的“副本”，通过使用import public表示来实现，具体可以参考如下例子。

       这时编译器就会在某些固定目录下查询import的proto文件（具体在命令行编译的时候，由-I/—proto_path指定），如果上述路径找不到，编译器会在调用路径进行查找。通常将—proto_path设置为项目的根目录，然后import的时候使用完整的路径名。

       3、使用proto2中的message类型

       proto2中的枚举类型无法直接使用。

       六、嵌套类型

       具体如下。

       在parent message之外调用嵌套的message可以用如下方式：SearchResponse.Result，嵌套结构可以更加复杂，具体如下：

       七、更新message类型

       当现有的message已经无法满足现有业务需要，你需要更新你的message类型以支持更复杂的业务，这就涉及到向后兼容的问题了，为保证已有服务不受影响，需要遵守以下的一些规定：

       1、不要更改已经存在的fields的数字标识

       2、如果添加新的field，利用旧代码序列化得到的message可以使用新的代码进行解析，你需要记住各个元素的默认值。新代码创建的field同样可以由旧代码进行加解析

       3、field可以被删除，但是需要保证其对应的数字标识不再被使用，你可以通过加前缀的方式来重新使用这个field name，或者指定数字标识为reserved来避免这种情况

       4、int、int、uint、uint、bool这些类型都是互相兼容的，并不会影响前向、后向兼容性

       5、sint和sint之间是互相兼容的，但是和其他数字类型是不兼容的

       6、string和bytes是互相兼容的，只要使用的是UTF-8编码

       7、如果byte包含message的编码版本，则嵌套的message和bytes兼容

       8、flexed兼容sfixed,fixed,sfixed

       9、enum兼容 int, uint, int, and uint。对于这个值在转化时，不同语言的客户端处理方式会有所不同

       感兴趣的小伙伴可以关注公众号：独立团丶