这是一个探索性质的项目,使用Java的新ffi为Java引入io_uring。
主要目的在于提供一个与基础read/write原语签名类似的 Linux异步文件I/O API,以补齐虚拟线程读写文件会导致pin住载体线程的短板。
这个项目并非与netty的io_uring一样会从系统调用开始处理,而是直接修改liburing 源码,在此基础上封装调用,即它最底层只是一层对liburing的封装。
maven坐标为
<dependency>
<groupId>io.github.dreamlike-ocean</groupId>
<artifactId>panama-uring-linux-x86_64</artifactId>
<version>3.0.2</version>
</dependency>
目前阶段参考价值大于实用价值,在jdk21之后我会做进一步的API适配,(垃圾java毁我人生,这东西jdk21稳定不了),Panama
API仍在变动之中
由于依赖了liburing的代码所以需要一并clone liburing仓库
git clone --recurse-submodules https://github.com/dreamlike-ocean/PanamaUring.git
注意:若无提及则均为one shot模式
- 异步读取
- 异步写入
- IOSQE_BUFFER_SELECT模式的异步读取
- 异步fsync
- 通过flock和定时任务实现的文件锁
- 异步connect (ipv4,ipv6)
- IOSQE_BUFFER_SELECT模式的异步recv
- 异步write
- mutlishot异步recv
- 异步accept
- multishot的异步accept
- 任意数量的IOSQE_IO_LINK
- 异步版本的splice api以及基于此的异步版本sendfile
- 异步的文件监听 inotify
- 异步的eventfd读写
- 异步的pipefd
- 基于Epoll的Async socket read,Async socket write,Async socket connect,Async socket accept
- 完整的Epoll绑定
- 完整的eventFd绑定
- 完整的unistd绑定
- 基于EventFd将IO Uring与Epoll连接在一起,socket api走Epoll驱动,收割cqe也由Epoll驱动,等价于Epoll监听IO Uring
- Panama FFI的声明式运行时绑定 点我看文档
初衷就是最小依赖,所以只依赖于jctools和slfj4,前者用于EventLoop的task queue,后者则是日志门面。jctools可以替换为juc的BlockingQueue的任意实现。
下面本人使用的构建工具以及运行环境:
注意 jdk版本不能升级也不能降级,Panama api可能不一致
- Maven 3.8.4
- OpenJDK 21
- Linux >= 5.10
- makefile GNU Make 4.3
构建非常简单
mvn clean package -DskipTests
由于io_uring的双环特性,其实推荐单线程获取sqe,然后同一线程再submit。
目前获取io_uring实例直接使用默认参数获取,所以使用的是io_uring_get_sqe
这个函数获取sqe,这个方法会导致从环上摘下一个sqe,而且封装的EventLoop带有一个定期submit的功能,所以要求io_uring_get_sqe
和sqe参数填充这多个操作必须是原子的
进而需要把这几个操作打包为一个操作切换到EventLoop上面执行
举个例子
public CompletableFuture<byte[]> readSelected(int offset, int length) {
CompletableFuture<byte[]> future = new CompletableFuture<>();
eventLoop.runOnEventLoop(() -> {
if (!uring.prep_selected_read(fd, offset, length, future)) {
future.completeExceptionally(new Exception("没有空闲的sqe"));
}
});
return future;
}
当EventLoop阻塞在wait cqe时,我们想要在任意线程里面唤醒它,最容易想到的就是使用 IORING_OP_NOP
这个OP, 但是这个也存在我们之前说的并发问题。
所以抄了一把jdk的selector实现,我会让io_uring监听一个eventfd,需要唤醒时我们只要增加一个eventfd的计数即可
注意这里的eventfd只是一个普通的fd,并非使用
io_uring_register_eventfd
这个方法来监听cqe完成事件的
wakeup的实现核心就这些。
然后我们来谈谈细节:
由于只支持one shot模式的监听,即submit一次sqe只会产生一次可读事件
所以需要读取到事件之后 再注册一次监听
private void multiShotReadEventfd() {
prep_read(wakeUpFd.getFd(), 0, wakeUpReadBuffer, (__) -> {
// 轮询到了直接再注册一个可读事件
wakeUpFd.read(wakeUpReadBuffer);
multiShotReadEventfd();
});
submit();
}
这里要保证两点
- 原子化——EventLoop机制保证
- 保证范围内的fd都属于同一个io_uring实现
比如说 asyncFile1和asyncFile2都必须是同一个io_uring
eventLoop.submitLinkedOpSafe(() -> {
asyncFile1.read();
asyncFile2.write();
});
还要支持捕获任意数量的AsyncFile
/AsyncSocket
/AsyncServerSocket
这里使用了一个针对于lambda实现的小技巧
private boolean checkCaptureContainAsyncFd(Object ops) {
try {
for (Field field : ops.getClass().getDeclaredFields()) {
if (!AsyncFd.class.isAssignableFrom(field.getType())) {
continue;
}
field.setAccessible(true);
IOUringEventLoop eventLoop = ((AsyncFd) field.get(ops)).fetchEventLoop();
if (eventLoop != this) {
return false;
}
}
} catch (Throwable t) {
throw new AssertionError("should not reach here", t);
}
return true;
}
为什么这里面会有Epoll?
因为最早的实现是,网络IO走epoll不变,文件IO走io_uring,epoll监听io_uring cqe完成事件的eventfd,当epoll轮询到这个eventfd时再去收割cqe。
但是目前我完整实现了这个EventLoop请看EpollUringEventLoop ,同时提供了基于Epoll的socket基础操作