1.I/O 简要分析
2.记一次源码追踪分析，从Java到JNI，再到JVM的C++：fileChannel.map()为什么快；源码分析map方法，put方法
3.Java的并行世界-Netty中线程模型源码讲解-续集Handler、Channel
4.Tars-Java网络编程源码分析
5.第12讲 |Java有几种文件拷贝方式？哪一种最高效？
6.架构师必知必会：Java内置的控制反转机制”Service Provider”

I/O 简要分析

       本文将从文件IO、网络IO和Java IO接口三个方面来分析IO操作。源码领域技术网

       一、文件IO

       一般情况下，我们通过调用read/write接口来进行IO操作，这种操作被称为标准IO，其会先经过页面缓存提高性能。直接IO则会直接作用到磁盘，优点是减少数据拷贝和系统调用消耗，降低CPU使用率和内存占用。还有一种mmap方法，即将文件或对象映射到进程地址空间，减少一次数据拷贝和系统调用。

       二、网络IO

       网络IO由Linux内核统一处理，包括socket读写、数据准备和数据复制两个阶段。网络IO模型包括同步阻塞、同步非阻塞、多路复用、信号驱动和异步IO。同步阻塞IO导致进程阻塞直到数据准备好。同步非阻塞IO则允许进程在等待数据时执行其他操作。多路复用IO则允许同时监听多个连接。信号驱动IO允许在数据准备时发送信号，而异步IO允许在调用后直接获得结果。

       三、Java IO接口

       Java IO接口包括BIO（同步阻塞IO）、NIO（同步非阻塞IO）、AIO（异步非阻塞IO）和Okio。ss协议源码BIO使用InputStream/OutputStream进行IO操作，NIO基于多路复用原理，使用channel、selector和Buffer处理多个连接。AIO在NIO基础上实现数据准备和拷贝的异步操作。Okio是Java IO的封装和优化，提供Sink、Source、TimeOut和Segment等核心类简化IO操作。

       总的来说，通过文件IO、网络IO和Java IO接口的不同模型，我们可以实现高效且灵活的IO操作。不同场景下选择合适的IO模型能够显著提高程序性能和效率。对于Okio的具体使用和详细架构，读者可以进一步探索其源码以深入了解。

记一次源码追踪分析，从Java到JNI，再到JVM的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为抽象类，且只有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/

Java的并行世界-Netty中线程模型源码讲解-续集Handler、Channel

       Netty 的核心组件 ChannelHandler 在网络应用中扮演着处理入站和出站事件及数据的关键角色。ChannelHandler 的子类负责执行不同类型的事件处理和数据操作，以实现特定的网络业务逻辑。以下是 ChannelHandler 子类的分类及其功能介绍：

       首先，特殊类型的Handler，如 ChannelHandlerContext，它连接了处理器与Channel之间的hibernate 方言 源码上下文关系，方便数据交互和事件触发。

       其次，ChannelInboundHandler 和 ChannelOutboundHandler 分别负责处理入站和出站的数据。ChannelInboundHandlerAdapter 示例如时间服务器，当连接建立时发送时间并断开，而 ChannelOutboundHandlerAdapter 则如客户端发送消息。

       ByteToMessageDecoder 和 MessageToByteEncoder 分别负责数据的解码和编码，如基于换行符的文本协议服务器和字符串消息的编码。

       ChannelDuplexHandler 如聊天服务器，处理双向通信，例如广播消息。SimpleChannelInboundHandler 提供了便捷的入站事件处理，避免了手动管理消息引用计数。

       Channel相关的核心概念是 Channel，它代表了网络连接，隐藏了底层通信方式的细节，支持数据读写和事件监听。Netty 提供了多种Channel子类，如 NioServerSocketChannel 和 EpollServerSocketChannel，用于适应不同应用场景。

       在服务器启动时，ChannelInitializer 用于初始化新连接的 ChannelPipeline，配置处理器以执行特定的业务逻辑。Netty 4.1 源码结构提供了学习的入口，后续会分享更详细的注释版源码。

       总的来说，通过理解和使用这些 ChannelHandler 和 Channel 的特性，开发者可以构建出功能丰富的网络应用。持续关注，将分享更多源码解析和学习资源。

Tars-Java网络编程源码分析

       Tars框架基本介绍

       Tars是腾讯开源的高性能RPC框架，支持多种语言，包括C++、Java、PHP、Nodejs、Go等。它提供了一整套解决方案，帮助开发者快速构建稳定可靠的分布式应用，并实现服务治理。

       Tars部署服务节点超过一千个，经过线上每日一百多亿消息推送量的考验。文章将从Java NIO网络编程原理和Tars使用NIO进行网络编程的细节两方面进行深入探讨。

       Java NIO原理介绍

       Java NIO提供了新的IO处理方式，它是面向缓冲区而不是字节流，且是非阻塞的，支持IO多路复用。

       Channel类型包括SocketChannel和ServerSocketChannel。ServerSocketChannel接受新连接，accept()方法会返回新连接的SocketChannel。Buffer类型用于数据读写，分配、读写、操作等。

       Selector用于监听多个通道的事件，单个线程可以监听多个数据通道。

       Tars NIO网络编程

       Tars采用多reactor多线程模型，核心类之间的关系明确。Java NIO服务端开发流程包括创建ServerSocketChannel、Selector、注册事件、循环处理IO事件等。

       Tars客户端发起请求流程包括创建通信器、工厂方法创建代理、初始化ServantClient、获取SelectorManager等。

       Tars服务端启动步骤包括初始化selectorManager、开启监听的ServerSocketChannel、选择reactor线程处理事件等。

       Reactor线程启动流程涉及多路复用器轮询检查事件、处理注册队列、获取已选键集中就绪的channel、更新Session、分发IO事件处理、处理注销队列等。

       IO事件分发处理涉及TCP和UDPAccepter处理不同事件，以及session中网络读写的详细处理过程。

       总结

       文章详细介绍了Java NIO编程原理和Tars-Java 1.7.2版本网络编程模块源码实现。最新的Tars-Java master分支已将网络编程改用Netty，学习NIO原理对掌握网络编程至关重要。

       了解更多关于Tars框架的介绍，请访问tarscloud.org。本文源码分析地址在github.com/TarsCloud/Ta...

第讲 |Java有几种文件拷贝方式？哪一种最高效？

       Java文件拷贝方式多种多样，主要包括利用java.io类库直接构建FileInputStream读取源文件，再构建FileOutputStream进行写入，或利用java.nio类库提供的transferTo或transferFrom方法。Java标准类库提供了Files.copy实现文件拷贝。在效率上，NIO transferTo/From方案可能更快，因为它能更高效地利用操作系统底层机制，减少不必要的拷贝和上下文切换。

       从实践角度，没有明确说NIO transfer的方案一定最快，真实情况也未必如此。面试官考察的是如何将猜测变成可验证的结论，思考方式比记住结论更重要。从技术角度，拷贝实现机制分析需要理解用户态空间和内核态空间，以及上下文切换带来的额外开销。NIO transferTo的实现方式在Linux和Unix上利用零拷贝技术，避免用户态参与，减少上下文切换和内存拷贝，提高应用拷贝性能。拷贝实现机制分析还需要关注Java IO/NIO源码结构，Java标准库的文件拷贝方法内部实现细节。

       提高IO操作性能的原则包括掌握NIO Buffer，了解Buffer的基本属性和操作，并熟悉Direct Buffer和垃圾收集机制。Direct Buffer在大数据量IO密集操作中有优势，但在创建和销毁过程中增加开销，适用于长期使用、数据较大的场景。Direct Buffer的内存管理需要关注内存设置、垃圾收集问题及回收策略。使用Native Memory Tracking（NMT）特性可以诊断Direct Buffer内存占用问题，但需要注意NMT对性能的影响。

架构师必知必会：Java内置的控制反转机制”Service Provider”

       Java在服务器编程领域持续主导，Spring框架以其基于控制反转（IoC）的思想，为依赖注入提供了强大的解决方案。然而，在某些特定场景下，如跨平台（如Android和服务端）组件组装或跨JVM语言集成，我们可能希望代码具有更低的依赖性，以适应更广泛的场景。从Java 6开始，Java内置了一套依赖注入的标准——“Service Provider”机制，以及相应的工具“ServiceLoader”，实现了控制反转的自定义实现。这一机制在JDK扩展设计中扮演着重要角色，如脚本引擎（ScriptEngine）、字符集（Charset）、文件系统（FileSystems）、网络通讯（NIO）等，被广泛应用。随着Java 9的发布，对“Service Provider”机制进行了进一步的扩展，使之适应了Java模块化的需求。因此，掌握“Service Provider”机制成为Java架构师不可或缺的知识之一。

       本文将引导读者通过JDK文档和源码探索“Service Provider”机制，学习如何使用Java内置能力实现动态依赖注入，或者按照Java标准扩展JDK、日志、HTTP服务的能力。

       “Service Provider”机制作为Javase的一部分，遵循着一套严格的标准定义，其核心内容包括了服务发布文件路径前缀、使用类加载器查找服务提供者文件、加载服务提供者类并创建服务提供者实例等关键步骤。通过“ServiceLoader.load()”方法，我们可以创建指定类型的“Service Provider”迭代器，通过遍历迭代器获取所有服务提供者的实例。这个过程涉及到了路径的解析、类的加载以及实例的创建，确保了服务提供者必须具有无参构造函数以便于创建实例。

       “Service Provider”机制在Web应用安全隔离中也发挥了重要作用，例如在实现Servlet3.0标准的“ServletContainerInitializer”应用自启动机制中，Tomcat采用了一套遵循“Service Provider”标准的服务查找实现“WebappServiceLoader”，这一实现与标准“ServiceLoader”有所区别，主要在于查找服务提供者文件的位置不同。

       “Service Provider”机制不仅扩展了JDK已有服务，如脚本引擎、字符集、文件系统、网络通讯等，还成为了扩展这些服务的标准选择。以脚本引擎ScriptEngine为例，Java内置了NashornScriptEngine支持直接解析和运行JavaScript脚本。通过“Service Provider”机制，我们可以轻松扩展ScriptEngine，支持其他脚本语言，如Python。ScriptEngineManager正是通过“ServiceLoader.load()”方法来发现所有脚本引擎实现，以实现动态加载。

       Servlet3.0的设计中，“ServletContainerInitializer”提供者通过“Service Provider”机制被发现并创建实例，进而触发用户自定义的初始化过程。例如，在Tomcat的源码中，`ContextConfig`和`StandardContext`类实现了这一机制，用于初始化Web应用。日志框架logback和Spring框架都利用了Servlet3.0的这一机制来初始化日志实现和Bean与服务提供者的集成，而Spring-Boot则进一步实现了Web应用拉起工具基类`SpringBootServletInitializer`，使得在Servlet容器中轻松启动Spring应用成为可能。最新版本的日志外观slf4j2.0和Logback1.3也采用“Service Provider”机制来加载日志实现。

       “Service Provider”机制的重要性体现在众多知名开源软件中的重视上，它不仅影响了开源软件的发展方向，而且对于想要为开源软件贡献代码，或者设计可扩展组件的架构师来说，掌握“Service Provider”机制是必不可少的技能。