2020 年 Google Summer of Code 创意
Netty 支持开箱即用的各种传输，具体取决于操作系统。目前它支持
- NIO 传输 - 在任何支持 Java 的平台/操作系统上运行
- 本机 Epoll 传输 - 仅在 Linux 上运行，并且根据使用的内核/GLIBC 版本提供各种功能
- 本机 Kqueue 传输 - 理论上可在任何 BSD 上运行，但主要在 MacOS 上进行测试。
由于大多数公司使用 Linux 作为生产系统的主操作系统，因此通常使用“本机 Epoll 传输”也就不足为奇了。虽然此传输已经比通用 NIO 传输提供了各种优势，但它仍然“遭受”一个与 NIO 传输相同的问题。它利用系统调用与系统/内核进行通信，以进行所有网络操作。
这包括（但不限于）
- 打开套接字
- 接受套接字
- 写入套接字
- 从套接字读取
- 关闭套接字
在过去几年中，使用系统调用为我们提供了很好的服务，但由于幽灵和熔毁，系统调用变得更加昂贵（并且将来很可能变得更加昂贵），因此有兴趣减少系统调用。
一种非常有前途的方法是 io_uring (https://kernel.dk/io_uring.pdf) [1, 2]。它提供了一个抽象和 API，允许与内核通信以进行 IO 操作，这几乎完全消除了对系统调用的需求。虽然解释 io_uring 的确切内部工作原理超出了本文的范围，但最重要的细节是它提供了一种通过使用映射到用户空间和内核空间的内存的环形缓冲区进行通信的方法。
为了确保 netty 可以在未来使用 io_uring，我们需要编写一个新的传输，该传输将使用提供的 API。由于这是使用 C API，因此需要通过 JNI（就像本机 Epoll 传输一样）来完成。
- 具有 Java 和 C 编程语言的经验（包括如何从 Java 代码中使用它 == JNI）
- 了解 Linux 及其网络 API
- 困难
- Francesco Nigro
- Norman Maurer
Netty 目前包含单元测试和集成测试的混合，这些测试作为公关验证的一部分运行，但也按夜运行。虽然这帮助我们确保我们在功能方面没有添加任何回归，但它无助于捕获其他类型的回归，例如
- 内存泄漏（本机和非本机）
- 内存开销
- 分配增加
- GC 压力
为了帮助我们检测这些类型的问题，我们希望增强当前的测试套件，以包括有助于确保我们在上述情况下不会出现回归的测试/工具。
- 能够将测试套件作为 CI 构建的一部分运行，并在检测到回归时使构建失败
- 生成显示与分配/内存使用等相关的趋势的图表
- 熟悉 Java
- 熟悉测试框架
- 熟悉 docker
- Francesco Nigro
- Norman Maurer
- 中等
- https://github.com/CodingFabian/allocation-tracker
- https://github.com/jvm-profiling-tools/async-profiler
- https://github.com/mariusae/heapster
Netty 附带了其自己的不同事件循环类型的实现，但它们缺乏可观察性：在它们上提供计数器和指标，以允许外部观察者了解它们的用法，将有助于用户调整和确认应用程序的性能瓶颈或错误配置以实现目标负载。可观察性通常需要付出代价，但理想情况下，它的影响应该可以通过它自己来衡量，并且经过精心设计和实现，尽可能更轻量级。
设计、实现和基准测试所提议的指标在不同用例中的有效性，以及在不使用遥测时与之相比的影响。
- 具有 Java 和基准测试经验
- [了解排队理论]
- 中等
- Francesco Nigro
- Norman Maurer
Netty 支持开箱即用的各种传输，具体取决于操作系统。目前它支持
- NIO 传输 - 在任何支持 Java 的平台/操作系统上运行
- 本机 Epoll 传输 - 仅在 Linux 上运行，并且根据使用的内核/GLIBC 版本提供各种功能
- 本机 Kqueue 传输 - 理论上可在任何 BSD 上运行，但主要在 MacOS 上进行测试。
最后两个在 Netty 本身中具有特定的 JNI 实现，而第一个利用 Java NIO 提供的内容进行了少量更改。可以在此类本机传输实现上收集特定指标和遥测数据，这有助于观察/解决正在运行的系统。
设计、实现和基准测试所提议的指标在不同用例中的有效性，以及在不使用遥测时与之相比的影响。
- 具有 Java 和基准测试经验
- 具有 Java 和 C 编程语言的经验（包括如何从 Java 代码中使用它 == JNI）
- 了解 Linux 及其网络 API
- 中等
- Francesco Nigro
- Norman Maurer