后端通信网络异步编程【免费下载链接】nettyNetty project - an event-driven asynchronous network application framework项目地址https://gitcode.com/gh_mirrors/ne/netty点击查看免费下载导读Netty 是一个异步事件驱动的网络应用框架用于快速开发可维护的高性能协议服务端与客户端其核心价值在于用统一的Channel/EventLoop/Pipeline抽象屏蔽底层 I/O 差异让开发者把精力集中在业务与协议编解码上。本指南以仓库根目录 README.md 为主线系统讲解 Netty 4.2 的运行环境要求、JDK 9 下的模块化JPMS使用方式、原生传输epoll/kqueue/io_uring与 HTTP/3、OpenSSL 的模块化引入并给出从源码构建、分支管理与为 Netty 贡献代码含 JPMS 开发者规范的完整实践路径。读完本文你将能够独立判断自己的项目该引入哪些 Netty 模块、如何在模块化运行时正确组装原生传输依赖以及如何在本地完成 Netty 的源码级构建与验证。Netty 是什么异步事件驱动网络框架的模块化布局Netty 的官方定位是 an asynchronous event-driven network application framework for rapid development of maintainable high performance protocol servers clients。它面向两类典型场景一是协议服务器/客户端的快速开发二是追求高吞吐、低延迟的网络中间件实现。从当前仓库的目录结构看Netty 采用 Maven 多模块工程父 POM 位于 pom.xml当前版本为4.2.19.Final-SNAPSHOT模块大致可分为四层核心层buffer字节缓冲抽象io.netty.buffer、common工具类、常量与并发原语io.netty.util、transportChannel、EventLoop、Bootstrap等传输抽象协议编解码层codec-base、codec-http、codec-http2、codec-http3、codec-dns、codec-mqtt、codec-redis、codec-socks、codec-stomp、codec-compression、codec-protobuf 等原生传输层transport-native-epoll、transport-native-kqueue、transport-native-io_uring、transport-native-unix-common测试与工具层testsuite、testsuite-jpms、microbench、example 等。理解这一分层是正确引入依赖的前提在 Netty 4.2 中Maven 模块与 Java 模块JPMS名称并不一一对应下文会详细说明映射关系。系统要求Java 版本与原生传输的特殊门槛根据 README.md 的明确说明Netty 4.2 要求 Java 8 或更高版本可选的io_uring原生传输要求 Java 9 或更高版本。这一门槛同样体现在构建环境中构建 Netty 需要最新稳定版 OpenJDK 8注意io_uring相关模块的构建需要 JDK 9以及最新稳定版 Apache Maven。关于运行时与构建时 JDK 的关系README 特别澄清上述 Java 8 是构建期要求历史版本中JDK 5针对 3.x或 JDK 6针对 4.0/4.1即可运行基于 Netty 的应用。也就是说构建工具链与最终运行环境对 JDK 的要求是分开的。io_uring 原生传输的额外前提transport-native-io_uring/README.md 给出了 io_uring 传输的详细运行前提处理器架构x86-64 / aarch64 / riscv64Linux 内核至少 5.14且编译时开启CONFIG_IO_URINGyJava 9与根 README 一致运行测试时需要提升 memlock 限制默认仅 64K。若在 memlock 不足时使用 io_uring会抛出形如java.lang.UnsatisfiedLinkError: failed to load the required native library、根因堆栈为failed to create io_uring ring fd Cannot allocate memory的异常。可通过ulimit -l查看当前 memlock 设置常见默认值为 65536单位 KB并提升使用 io_uring 用户的 memlock 上限。引入 io_uring 依赖时必须指定分类器classifier例如 x86_64 平台dependency groupIdio.netty/groupId artifactIdnetty-transport-native-io_uring/artifactId version${netty.version}/version classifierlinux-x86_64/classifier /dependencyGradle 写法等价为dependencies { implementation io.netty:netty-transport-native-io_uring:${netty.version}:linux-x86_64 }JDK 9 模块化使用从自动模块到显式模块自 JDK 9 引入 Java Platform Module SystemJPMS以来Netty 对模块化的支持经历了两次演进Netty 4.1以**命名自动模块named automatic modules**的形式被引用Netty 4.2提供显式模块explicit modules即每个 Maven 子模块在 jar 中携带完整的module-info.class描述符。模块命名规则由于历史原因Netty 的 Java 模块名遵循反向 DNS 风格但来源于子项目名称而非根包名。完整模块清单如下摘自 testsuite-jpms/README.md模块名对应内容io.netty.buffer字节缓冲io.netty.common通用工具io.netty.transport传输核心抽象io.netty.handlerhandler 实现io.netty.handler.proxy代理 handlerio.netty.handler.ssl.ocspOCSP staplingio.netty.codec基础编解码io.netty.codec.dns/codec.http/codec.http2/codec.http3/codec.memcache/codec.mqtt/codec.redis/codec.smtp/codec.socks/codec.stomp/codec.xml/codec.haproxy各协议编解码io.netty.codec.compression/codec.marshalling/codec.protobuf压缩、Java 序列化、Protobufio.netty.codec.quic.${os.name}.${os.arch}HTTP/3QUIC原生库io.netty.codec.classes.quicHTTP/3 的 Java 类io.netty.resolver/io.netty.resolver.dns/io.netty.resolver.dns.classes.macos地址解析与 DNSio.netty.internal.tcnative.openssl.${os.name}.${os.arch}OpenSSL 原生库io.netty.tcnative.classes.opensslOpenSSL 的 Java 类io.netty.transport.classes.${transport}原生传输的 Java 类如EpollServerSocketChannelio.netty.transport.${transport}及io.netty.transport.${transport}.${os.name}.${os.arch}原生传输模块含运行时原生库io.netty.transport.unix.commonUnix 公共原生支持其中${transport}可取epoll、kqueue或io_uring。注意两个命名细节一是由于native是 Java 保留字原生相关模块名中省略了 native 字样二是io.netty.transport.${transport}.${os.name}.${os.arch}这类含操作系统/架构的模块其os.name/os.arch在仓库实际构建中由检测属性如${os.detected.name}、${os.detected.arch}填充可参见 testsuite-jpms/pom.xml 中 maven-jlink-plugin 的addModules配置。模块封装策略与第三方依赖Netty 的显式模块不使用强封装strong encapsulation所有 Java 包均被导出这降低了用户拼接模块的出错概率。此外少数 Maven 模块不再支持 JPMS包括netty-transport-rxtx、netty-transport-sctp、netty-transport-udt即仓库中的 transport-rxtx、transport-sctp、transport-udt。这些模块应仅在非模块化classpath运行时使用。对于依赖第三方库的模块JPMS 支持程度不一部分依赖是可选optional的。官方汇总如下模块依赖状态可选io.netty.commonorg.apache.commons.loggingexplicit是io.netty.commonorg.apache.log4jexplicit是io.netty.commonorg.apache.logging.log4jexplicit是io.netty.commonorg.slf4jexplicit是io.netty.codec.protobufcom.google.protobufautomatic否io.netty.codec.protobufprotobuf.nanoautomatic否io.netty.codec.marshallingjboss.marshallingautomatic否io.netty.codec.compressioncom.aayushatharva.brotli4jexplicit是io.netty.codec.compressioncom.github.luben.zstd_jniexplicit是io.netty.codec.compressioncompress.lzfexplicit是io.netty.codec.compressionjzlibautomatic是io.netty.codec.compressionlz4automatic是io.netty.codec.compressionlzma.javaautomatic是io.netty.codec.xmlcom.fasterxml.aaltoexplicit否io.netty.handlerorg.bouncycastle.pkixexplicit是io.netty.handlerorg.bouncycastle.providerexplicit是io.netty.handlerorg.conscryptautomatic是其中 explicit 表示该依赖 jar 自带module-info.class描述符多版本 jar 则位于META-INF/versions/*/automatic 表示依赖仅声明了Automatic-Module-Name。io.netty.codec 模块的拆分4.2 的重要变更Netty 4.2 将io-netty-codecMaven 模块拆分为 4 个模块io-netty-codec-base声明io.netty.codecJava 模块包含io.netty.handler.codecJava 包以及不依赖第三方库的内置编解码器base64、bytes、json、serialization、string子包。其模块描述见 codec-base/src/main/java/module-info.yml声明了requires io.netty.transport / io.netty.buffer / io.netty.commonio-netty-codec-compression声明io.netty.codec.compressionJava 模块包含io.netty.handler.codec.compression包可选依赖 Brotli4j 等压缩库io-netty-codec-protobuf声明io.netty.codec.protobufJava 模块依赖 Google Protobufio-netty-codec-marshalling声明io.netty.codec.marshallingJava 模块依赖 JBoss Marshalling。为保持向后兼容原io-netty-codecMaven 模块继续存在并传递依赖以上 4 个模块同时额外声明了一个空的io.netty.codec.unusedJPMS 模块以满足 jlink 等要求模块化 jar 的工具。这意味着依赖io-netty-codec会一并带入 compression/protobuf/marshalling如果不需要其中某些能力可以直接排除对应依赖或改为只依赖io-netty-codec-base。原生传输、HTTP/3 与 OpenSSL 的模块化引入三类带原生库的特性在 JPMS 下的引入模式完全一致原则是**“类模块编译期必需、原生库模块仅运行期必需”**原生传输epoll/kqueue/io_uringio.netty.transport.classes.${transport}包含传输类如EpollServerSocketChannel必须在编译与运行期都存在io.netty.transport.${transport}.${os.name}.${os.arch}包含原生库只需在运行期以requires声明或置于模块路径上。由于os/arch随环境变化推荐做法是只依赖类模块在运行期按需添加对应的原生库模块HTTP/3io.netty.codec.classes.quic是必需的类模块io.netty.codec.quic.${os.name}.${os.arch}是运行期可选的原生库模块OpenSSLio.netty.tcnative.classes.openssl是必需的类模块io.netty.internal.tcnative.openssl.${os.name}.${os.arch}是运行期可选的原生库模块压缩压缩类模块仅在对应算法真正被使用时才需要引入。使用 jlink 制作应用镜像jlink工具可以生成自包含的应用镜像Netty 对此提供支持但有条件限制来源于依赖方——被链接进镜像的依赖必须是显式模块提供module-info.class描述符。哪些依赖满足条件可对照上文“第三方依赖”表格判断。若依赖是自动模块jlink会拒绝将其纳入镜像。实战示例模块化 HTTP 服务器testsuite-jpmstestsuite-jpms 模块同时承载了两重职责作为示例演示模块化应用如何组装 Netty以及作为集成测试套件在模块化运行时验证各功能。示例程序与命令行参数示例主类是 HttpHelloWorldServer.java一个可同时演示多种能力的 HTTP 服务器支持选择传输类型、启用 SSLJDK/OpenSSL 两种 provider以及 HTTP/3。其--help输出如下usage: [options] --ssl --ssl-provider [ JDK | OPENSSL ] --port port --transport [ nio | kqueue | epoll | io_uring ] --http3关键行为说明可从源码直接印证默认端口启用 SSL 时默认8443否则默认8080见 HttpHelloWorldServer.java传输选择nioNioIoHandler/NioServerSocketChannel、kqueueKQueueIoHandler/KQueueServerSocketChannel、epollEpollIoHandler/EpollServerSocketChannel、io_uringIoUringIoHandler/IoUringServerSocketChannel四选一HTTP/3 模式基于QuicSslContextBuilder.forServer(...)构建 QUIC 上下文并用Http3.newQuicServerCodecBuilder()组装编解码器与令牌校验InsecureQuicTokenHandler底层以NioDatagramChannel承载 UDP 数据报输出内容响应正文包含所用Channel实现类名、可用的 SSL 引擎类名以及启动层Boot layer全部模块名清单对自动模块会标注(automatic)。运行方式通过 maven-jlink-plugin配置见 testsuite-jpms/pom.xml生成镜像后可用java以模块主类方式启动或使用快捷启动器http./target/maven-jlink/default/bin/java -m io.netty.testsuite_jpms.main/io.netty.testsuite_jpms.main.HttpHelloWorldServer ./target/maven-jlink/default/bin/http --help典型组合示例其中--add-modules用于把运行期才需要的原生库模块挂到模块路径修改端口...HttpHelloWorldServer --port 80启用 SSL...HttpHelloWorldServer --ssl使用 OpenSSL providermacOS/aarch64 示例--add-modules io.netty.internal.tcnative.openssl.osx.aarch_64 -m ...HttpHelloWorldServer --ssl --ssl-provider OPENSSL使用 kqueue 原生传输--add-modules io.netty.transport.kqueue.osx.aarch_64 -m ...HttpHelloWorldServer --transport kqueue启用 HTTP/3--add-modules io.netty.codec.quic.osx.aarch_64 -m ...HttpHelloWorldServer --http3启动后浏览器访问对应端口页面会展示 Hello World、当前Transport实现类以及 Boot layer 模块清单——这是验证模块化组装是否正确的最直观手段。该示例的 SSL 证书通过 pkitesting 模块的CertificateBuilder生成自签名证书仅供本地演示。如何从源码构建 Netty构建 Netty 需准备以下环境构建期要求区别于运行期要求最新稳定版 OpenJDK 8io_uring相关模块需要 JDK 9最新稳定版 Apache MavenLinux 或 macOS 上还需安装额外的开发包因为构建过程会同时编译原生传输C 代码相关说明见仓库中的 transport-native-epoll、transport-native-kqueue、transport-native-io_uring 等原生模块。仓库根目录提供了 Maven Wrappermvnw可直接使用./mvnw执行构建或使用系统 Maven。构建入口是根目录的 pom.xmlparent POMio.netty:netty-parent它聚合了全部子模块。子模块众多构建耗时较长若只需编译某模块可结合-pl指定模块例如./mvnw -pl buffer -am compile。注意原生模块如transport-native-epoll在非目标平台或缺少本地工具链时会受 Maven profile 与 classifier 约束跨平台构建需参考各原生模块目录下的说明例如 docker 目录提供了 CentOS 7 等多套构建镜像与 compose 配置。从构建配置可以进一步确认 JPMS 的实现方式Netty 4.2 面向 Java 8 编译但通过 module-info Maven 插件由module-info.yml源文件生成module-info.classYML 即module-info.java的等价物。各模块的模块描述符可从仓库直接查阅例如buffer/src/main/java/module-info.ymlrequires io.netty.common并对jdk.jfr使用static: true可选依赖codec-base/src/main/java/module-info.ymlrequires io.netty.transport / io.netty.buffer / io.netty.commoncommon/src/main/java/module-info.yml对应io.netty.common模块。每个模块的module-info.yml位于src/main/java/module-info.yml是理解“Maven 模块 ↔ Java 模块 ↔ 依赖关系”的第一手材料。版本管理与分支策略Netty 所有版本的开发都在以majorVersion.minorVersion命名的分支上进行。例如 3.9 版本的开发位于分支3.94.1 版本的开发位于分支4.1。这意味着如果希望在特定主/次版本上跟踪最新改动或提交补丁应切换到对应数字分支而不是在主干上操作。开发者指南为 Netty 贡献代码时的 JPMS 规范testsuite-jpms/README.md 的 Developer guide 部分为不熟悉 JPMS 的贡献者整理了必须遵守的规则新增 Java 包不得造成拆分包split package新包不能出现在 Netty 其他模块中否则模块系统会拒绝加载。目前尚无自动化工具检查这一点需开发者自觉避免4.2 的模块化改造已消除了历史遗留的拆分包新增外部依赖优先选择显式模块显式模块指 jar 根部或META-INF/versions/*/中含module-info.class多版本 jar 场景Netty 自身亦如此。若实在无法避免自动模块仅声明了Automatic-Module-Name的 jar有两种降级手段声明为可选依赖requires static如io.netty.codec.compression对jzlib的做法或新建独立 Maven 模块来解耦META-INF services 使用Netty 与 SPI 服务交互不多ChannelInitializerExtension是当前唯一的 service 使用场景因此在module-info.yml描述符中显式声明该扩展JPMS 测试新特性不强制要求 JPMS 测试但集成测试能确保功能在模块化运行时可用——因为 Java 的动态特性常使模块问题到运行时才暴露。testsuite-jpms提供了一整套在模块化运行时执行的测试Surefire 通过classpathDependencyExcludes把依赖 jar 全部从 classpath 剔除使测试只走模块路径配置见 testsuite-jpms/pom.xml并针对 slf4j、log4j、commons-logging 分别配置了独立执行execution以覆盖日志依赖的可选性IDE 支持由于 Netty 模块缺少module-info.java描述符由构建期插件从 yml 生成在默认 Netty 工程中调试 JPMS 测试套件可能让 IDE 困惑可将 testsuite-jpms/pom.xml 作为独立项目加载IDE 会从本地快照仓库解析已构建的模块 jar原生库加载Netty 原生库资源位于包结构之外例如META-INF/native/libnetty_quiche42_osx_aarch_64.jnilib。因此原生库模块无需导出包可被任意模块加载它们编译期无需存在运行期才需要——这正是前文“类模块 运行期原生模块”模式成立的根本原因。小结运行Netty 4.2 至少需要 Java 8io_uring 传输需 Java 9引入原生传输时务必带 classifier模块化4.2 提供显式模块模块名以反向 DNS 风格取自子项目名原生/QUIC/OpenSSL 原生库模块仅运行期必需建议编译期只依赖类模块构建需要 OpenJDK 8 MavenLinux/macOS 需原生开发包模块描述符由module-info.yml经构建插件生成可直接在仓库各模块src/main/java/下查阅验证testsuite-jpms 的模块化 HTTP 服务器示例与测试套件是学习模块化组装与排查模块问题的第一现场。赞分享后端通信网络异步编程【免费下载链接】nettyNetty project - an event-driven asynchronous network application framework项目地址https://gitcode.com/gh_mirrors/ne/netty点击查看免费下载相关推荐ok-ww鸣潮自动化完整指南三步搞定自动战斗、声骸刷取与日常托管ok ww鸣潮自动化完整指南三步搞定自动战斗、声骸刷取与日常托管 你终于下班回家打开《鸣潮》等待你的还是那套固定流程跑塔、清日常、刷声骸。免费开源工具okGUI 自动化计算机视觉RPA人工智能NVIDIA Thrust项目使用与构建的系统要求详解NVIDIA Thrust项目使用与构建的系统要求详解 前言 NVIDIA Thrust是一个基于C的并行算法库它提供了类似于C标准模板库 STL 的科学计算kitty 源码构建完全指南:dev.sh 构建系统、依赖管理、调试构建与打包实践kitty 源码构建完全指南:dev.sh 构建系统、依赖管理、调试构建与打包实践 本文基于 kitty 官方文档 docs/build.rst https:/桌面应用上一篇革命性无人机探索框架FUEL3-8倍速超越传统方法的核心秘密下一篇React-Three-Fiber终极指南从零构建惊艳3D交互应用创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考