getty 发布,一个完全基于 java 实现的 aio 框架
说说写这个框架的原因:
1、作者本人是一个码农,比较喜欢研究技术,特别是网络通讯。
2、JDK1.7升级了NIO类库,升级后的NIO类库被称为NIO 2.0。正式提供了异步文件I/O操作,同时提供了与UNIX网络编程事件驱动I/O对应的AIO。AIO的发布使得实现一套网络通讯框架变得相对简单。但如果你不努力,可能也无法理解哦。
3、本人对netty比较喜欢,无论是其性能还是编程思想(JBOSS提供的一个java开源网络框架,可以说是java网络通讯里的一哥,极其稳定和强大的性能使得被广泛使用)
4、有了netty为何还要自己造轮子?这里有两个原因,其一是本人就喜欢造轮子,这是病,改不了。其二,netty经过多年的发展,其生态体系已经比较庞大,导致其代码比较臃肿,再者其高深的设计哲学我等凡夫俗子很难悟其精髓。因而索性自己造一个。
5、netty毕竟是别人的东西,还是老外的。并且国内也有许多优秀的开源框架。想了想,为何不自己搞一个呢,于是乎脑袋发热,抽时间造了一个。
说说getty的特点:
1、完全基于java aio,整个工程只依赖 slf4j(一个日志的门面框架),对工程几乎没有入侵性。
2、借鉴了netty和其他框架的部分优秀设计思想,如责任链、内存池化、零拷贝等优秀的设计模式。
3、简洁的代码,清晰的注释,以及提供了直接可用的多个插件,只要用过netty,那么学习成本基本为零。
4、可直接在安卓上使用,服务与客户端使用几乎一致(api 26+或android 8.0+)
说说getty的性能和稳定性:
硬件条件:cpu:i7-7700 | 内存:16G | 网络:局域网 | 操作系统:win10家庭版 | jdk 8
经过本人简单的测试,整体的性能和稳定性还是不错的:
1、单连接发送一百万条文本消息耗时277毫秒,这个性能总体上还过得去。
2、开启了SSL以后发送一百万条文本消息大概耗时3.8秒,这个性能也算乐观,因为毕竟SSL本身对消息的加密和解密是非常消耗性能的。
3、同时开启10条连接,每条连接发送一百万条文本消息,每条连接平均耗时是比较均衡的,平均三百多毫秒。性能非常可观
4、服务器启动时的内存消耗,启动时内存消耗非常小,占用还不到40m
5、连续发送一百万条消息时的内存消耗,大概消耗160m左右,而且内存回收也非常迅速
如何使用:
先添加 slf4j 依赖:
//java 中使用 <dependency> <groupId>org.slf4j</groupId> <artifactId>slf4j-api</artifactId> </dependency>
安卓中使用添加安卓版本:
// https://mvnrepository.com/artifact/org.slf4j/slf4j-android implementation group: 'org.slf4j', name: 'slf4j-android', version: '1.7.26'
1、服务器端启动:
AioServerStarter server = new AioServerStarter(5555); server.bossThreadNum(10).channelInitializer(new ChannelInitializer() { @Override public void initChannel(AioChannel channel) throws Exception { //初始化责任链 DefaultChannelPipeline defaultChannelPipeline = channel.getDefaultChannelPipeline(); //添加结束符处理器 defaultChannelPipeline.addLast(new DelimiterFrameDecoder(DelimiterFrameDecoder.lineDelimiter)); //添加string类型消息解码器 defaultChannelPipeline.addLast(new StringDecoder()); //自定义的消息处理器 defaultChannelPipeline.addLast(new SimpleHandler()); } }); server.start();
//简单的消息处理器 public class SimpleHandler extends SimpleChannelInboundHandler<String> { @Override public void channelAdded(AioChannel aioChannel) { System.out.println("连接过来了"); } @Override public void channelClosed(AioChannel aioChannel) { System.out.println("连接关闭了"); } @Override public void channelRead0(AioChannel aioChannel, String str) { System.out.println("读取消息:" +str); try { byte[] msgBody = (str + "\r\n").getBytes("utf-8"); //返回消息给客户端 aioChannel.writeAndFlush(msgBody); } catch (UnsupportedEncodingException e) { e.printStackTrace(); } } @Override public void exceptionCaught(AioChannel aioChannel, Throwable cause, PipelineDirection pipelineDirection) { System.out.println("出错了"); } }
2、客户端启动:
AioClientStarter client = new AioClientStarter("127.0.0.1", port); client.channelInitializer(new ChannelInitializer() { @Override public void initChannel(AioChannel channel) throws Exception { //责任链 DefaultChannelPipeline defaultChannelPipeline = channel.getDefaultChannelPipeline(); //字符串编码器 defaultChannelPipeline.addLast(new StringEncoder()); //指定结束符解码器 defaultChannelPipeline.addLast(new DelimiterFrameDecoder(DelimiterFrameDecoder.lineDelimiter)); //字符串解码器 defaultChannelPipeline.addLast(new StringDecoder()); //定义消息解码器 defaultChannelPipeline.addLast(new SimpleHandler()); } }); try { client.start(); Thread.sleep(1000); //获取通道 AioChannel aioChannel = client.getAioChannel(); //发送消息 String s = "me\r\n"; byte[] msgBody = s.getBytes("utf-8"); aioChannel.writeAndFlush(msgBody); } catch (Exception e) { e.printStackTrace(); }
最简单的使用方式就完成了。
更多详情可以查看码云:https://gitee.com/kokjuis/getty

低调大师中文资讯倾力打造互联网数据资讯、行业资源、电子商务、移动互联网、网络营销平台。
持续更新报道IT业界、互联网、市场资讯、驱动更新,是最及时权威的产业资讯及硬件资讯报道平台。
转载内容版权归作者及来源网站所有,本站原创内容转载请注明来源。
- 上一篇
跑的好好的 Java 进程,怎么突然就瘫痪了
内存回收一直是 Java的痛点 用 Java 无法做出类似 Redis 这样的产品。Java 的内存回收机制使我们在编写代码时不需要关注对象的回收,同时加大了内存回收的消耗,标记复制需要做内存拷贝,标记清除算法则需要 stop the world 。所以我们在使用缓存的时候,量稍微大一些就需要借助类似 Redis 这样的中间件帮我们处理了。作为 Javaer ,我们享受了自动内存回收的安逸,同时也需要多了解下内存优化的方法。 为什么 FGC 停不下来了 什么情况下会 GC 为了了解我们的系统为什么会不停 FGC ,我们需要先了解一下系统什么情况下会 GC 。在 Jvm 层面,当我们 new 一个对象的时候, Jvm 会先在堆区分配对象需要的内存,这个时候如果内存不够的话,就需要 GC 了, GC 的返回结果就是对象的空间地址。Jvm 会先进行 ygc ,也就是我们通常说的标记复制,如果 ygc 之后依然申请不到空间,就会进行 FGC 了。同理,如果 FGC 之后依然没有足够的空间,就会循环的进行 FGC ,直到申请到足够的空间。 导致不停的 FGC 的原因 如上文所讲, FGC 有可能...
- 下一篇
使用Packer实现自动化构建UCloud云主机镜像
背景 云主机是用户使用最高频的云产品之一。随着云主机数量的增多,如何在云主机中保证版本化部署的一致性,成为用户常见的难题。在现有情况下,用户首先需要手动或使用脚本连接主机,然后再进行部署安装,操作流程复杂且对环境要求苛刻,难以保证一致性和可用性。 为了解决此类问题,UCloud 开发了相关代码,并被自动化构建镜像工具 Packer 的官方仓库所采纳。通过 Packer 创建自定义镜像,可以减少部署时间并提高可靠性,提高了用户自动化部署的能力。8月14日,Hashicorp 官方正式发布了版本 1.4.3 ,其中包括了 UCloud Packer Builder。 Packer是什么? Packer 是 Hashicorp 公司推出的自动化打包镜像的轻量级开源工具,云厂商通过构建自己的 Builder 集成到 Packer 中去,即可凭借单一配置文件,高效并行的为多云平台创建一致性的镜像。目前 Packer 已经形成完整生态,并与多家主流云厂商建立合作。 UCloud Packer 可以运行在常用的主流操作系统上,它不是 Chef、Puppet 等软件的替代品,而是集成并使用这些自动化配...
相关文章
文章评论
共有0条评论来说两句吧...
文章二维码
点击排行
推荐阅读
最新文章
- SpringBoot2整合Redis,开启缓存,提高访问速度
- SpringBoot2编写第一个Controller,响应你的http请求并返回结果
- SpringBoot2更换Tomcat为Jetty,小型站点的福音
- CentOS8,CentOS7,CentOS6编译安装Redis5.0.7
- Jdk安装(Linux,MacOS,Windows),包含三大操作系统的最全安装
- CentOS8编译安装MySQL8.0.19
- Springboot2将连接池hikari替换为druid,体验最强大的数据库连接池
- SpringBoot2整合Thymeleaf,官方推荐html解决方案
- CentOS7编译安装Gcc9.2.0,解决mysql等软件编译问题
- Docker使用Oracle官方镜像安装(12C,18C,19C)