netty高性能网络框架原理
发表于|更新于|后端
|浏览量:
https://www.processon.com/view/608e06281e085376286d72ef?fromnew=1

文章作者: 褚成志
相关推荐
2026-04-09
netty高性能网络框架涉及的核心组件
https://www.processon.com/view/60ddbec51efad40c1bf0210d?fromnew=1
2026-04-09
Netty的整体结构
Netty 的整体结构 https://netty.io/ Netty是一个NIO客户端服务器框架,可以快速轻松地开发网络应用程序,例如协议服务器和客户端。 它极大地简化和简化了诸如TCP和UDP套接字服务器之类的网络编程。 “快速简便”并不意味着最终的应用程序将遭受可维护性或性能问题的困扰。 Netty经过精心设计,结合了许多协议(例如FTP,SMTP,HTTP以及各种基于二进制和文本的旧式协议)的实施经验。 结果,Netty成功地找到了一种无需妥协即可轻松实现开发,性能,稳定性和灵活性的方法。 设计:适用于各种传输类型的统一API-阻塞和非阻塞套接字。基于灵活且可扩展的事件模型,可将关注点明确分离。高度可定制的线程模型:单线程,一个或多个线程池,例如SEDA。真正的无连接数据报套接字支持(从3.1开始) 使用方便:记录良好的Javadoc,用户指南和示例,没有其他依赖关系,JDK 5(Netty 3.x)或6(Netty 4.x)就足够了 表现:更高的吞吐量,更低的延迟。减少资源消耗。减少不必要的内存复制 安全:完整的SSL / TLS和StartTLS支持 ...
2026-04-09
netty--源码流程--结合NIO点位
https://www.processon.com/view/60ddb9aae0b34d238be316ca?fromnew=1
2026-04-09
netty思维导图总结
https://www.processon.com/view/link/610420f01e0853746618739d
2026-04-09
读取了Request输入流,请求数据就不见了
HttpServletRequest 和 HttpServletResponse 中存在方法互斥。 在过滤器、拦截器中对 HTTP 请求中的数据做校验、审计是非常常见的需求 Request 输入流数据一但被读取,Controller找不到了Request 的 getlnputStream 和 getReader 都只能使用一次 请求数据解析工具: 定义拦截器: 发起请求: Request的 getlnputStream、 getReader、 getParameter 方法互斥,也就是使用了其中一个,再使用另外的两个,是获取不到数据的。 Response 也是一样的,与 Request 几乎是一样的 互斥效果的原理: getParameter 内部也会判断: 无法重复读取的原理读取完坐标没有重置: getReader 也是没有重置坐标 HttpServletRequestWrapper + Filter 解决输入流不能重复读取问题其实是包装器模式,实现对请求数据的包装。 自定义请求包装器: 每次获取数据的时候都是重新从数组里面获取 这个方法直接调用上面重写的 g...
2026-04-09
异步任务的坑
Spring Boot 中编写异步任务两个注解: @EnableAsync:开启当前项目的异步功能 @Async:当前方法标记为异步方法 注意一个规则:有没有返回值。 没有返回值的例子: 返回值实现了 Future 接口: 下 异步任务的线程池配置默认情况下,异步任务的线程池是怎么配置的,是否满足我们的需求呢? 配置线程池参数默认是启动下面的线程池: 线程池对应的自动配置类如下: 可以使用下面的参数配置异步任务线程池相关的参数: 异步任务返回超时对于异步任务有返回的情况,如果获取结果超时怎么办呢? get 有重载方法可以设置超时的时间,超时之后就会抛出 TimeOut 异常: 没有返回值的异步任务抛异常对于异步任务没有返回的情况(有返回的直接 get 的时候就会抛异常),但是下面的异步任务执行的时候抛出异常,但是没有任何的其他返回: Spring 默认的异步任务异常处理器,会将对应的异常打印到日志里面: 自定义异步线程池和异常处理器 自定义异步线程池的实现: 自定义异常处理器
公告
👋 你好,我是褚成志,一名专注于云原生与后端架构的工程师。
热爱 Java、Kubernetes、Linux、Redis、Spring 等技术领域,持续探索 AGI 与智能化运维的边界。
这里记录我的技术思考与实践总结,欢迎交流!
热爱 Java、Kubernetes、Linux、Redis、Spring 等技术领域,持续探索 AGI 与智能化运维的边界。
这里记录我的技术思考与实践总结,欢迎交流!
