「javanio通信」java系统间通信

博主:adminadmin 2023-03-21 13:42:08 732

今天给各位分享javanio通信的知识,其中也会对java系统间通信进行解释,如果能碰巧解决你现在面临的问题,别忘了关注本站,现在开始吧!

本文目录一览:

Java中IO与NIO的区别和使用场景

在java2以前,传统的socket IO中,需要为每个连接创建一个线程,当并发的连接数量非常巨大时,线程所占用的栈内存和CPU线程切换的开销将非常巨大。java5以后使用NIO,不再需要为每个线程创建单独的线程,可以用一个含有限数量线程的线程池,甚至一个线程来为任意数量的连接服务。由于线程数量小于连接数量,所以每个线程进行IO操作时就不能阻塞,如果阻塞的话,有些连接就得不到处理,NIO提供了这种非阻塞的能力。

NIO 设计背后的基石:反应器模式,用于事件多路分离和分派的体系结构模式。

反应器(Reactor):用于事件多路分离和分派的体系结构模式

通常的,对一个文件描述符指定的文件或设备, 有两种工作方式: 阻塞 与非阻塞 。所谓阻塞方式的意思是指, 当试图对该文件描述符进行读写时, 如果当时没有东西可读,或者暂时不可写, 程序就进入等待 状态, 直到有东西可读或者可写为止。而对于非阻塞状态, 如果没有东西可读, 或者不可写, 读写函数马上返回, 而不会等待 。

一种常用做法是:每建立一个Socket连接时,同时创建一个新线程对该Socket进行单独通信(采用阻塞的方式通信)。这种方式具有很高的响应速度,并且控制起来也很简单,在连接数较少的时候非常有效,但是如果对每一个连接都产生一个线程的无疑是对系统资源的一种浪费,如果连接数较多将会出现资源不足的情况。

另一种较高效的做法是:服务器端保存一个Socket连接列表,然后对这个列表进行轮询,如果发现某个Socket端口上有数据可读时(读就绪),则调用该socket连接的相应读操作;如果发现某个 Socket端口上有数据可写时(写就绪),则调用该socket连接的相应写操作;如果某个端口的Socket连接已经中断,则调用相应的析构方法关闭该端口。这样能充分利用服务器资源,效率得到了很大提高。

传统的阻塞式IO,每个连接必须要开一个线程来处理,并且没处理完线程不能退出。

非阻塞式IO,由于基于反应器模式,用于事件多路分离和分派的体系结构模式,所以可以利用线程池来处理。事件来了就处理,处理完了就把线程归还。而传统阻塞方式不能使用线程池来处理,假设当前有10000个连接,非阻塞方式可能用1000个线程的线程池就搞定了,而传统阻塞方式就需要开10000个来处理。如果连接数较多将会出现资源不足的情况。非阻塞的核心优势就在这里。

为什么会这样,下面就对他们做进一步细致具体的分析:

首先,我们来分析传统阻塞式IO的瓶颈在哪里。在连接数不多的情况下,传统IO编写容易方便使用。但是随着连接数的增多,问题传统IO就不行了。因为前面说过,传统IO处理每个连接都要消耗一个线程,而程序的效率当线程数不多时是随着线程数的增加而增加,但是到一定的数量之后,是随着线程数的增加而减少。这里我们得出结论,传统阻塞式IO的瓶颈在于不能处理过多的连接。

然后,非阻塞式IO的出现的目的就是为了解决这个瓶颈。而非阻塞式IO是怎么实现的呢?非阻塞IO处理连接的线程数和连接数没有联系,也就是说处理 10000个连接非阻塞IO不需要10000个线程,你可以用1000个也可以用2000个线程来处理。因为非阻塞IO处理连接是异步的。当某个链接发送请求到服务器,服务器把这个连接请求当作一个请求"事件",并把这个"事件"分配给相应的函数处理。我们可以把这个处理函数放到线程中去执行,执行完就把线程归还。这样一个线程就可以异步的处理多个事件。而阻塞式IO的线程的大部分时间都浪费在等待请求上了。

所谓阻塞式IO流,就是指在从数据流当中读写数据的的时候,阻塞当前线程,直到IO流可以

重新使用为止,你也可以使用流的avaliableBytes()函数看看当前流当中有多少字节可以读取,这样

就不会再阻塞了。

JAVA 非阻塞通信(NIO)相比普通socket通信,非阻塞表现在哪里?本质区别是什么?

0,重连,重新再来过一次呗。

1,NIO 本身是提供非阻塞式的网络访问,使用 selector 来轮询事件,因此用 selector 才能改进性能,一个 selector 可以用在多个 socket 通信中而不像以前传统的一个线程一个 socket 流这么麻烦地管理它们。

2,客户端与服务端是互不影响的,完全不相关。我们完全不需要关心对方是C++ / VB 还是 Java ,只要双方使用的都是 TCP 协议就行了。

NIO 是在与操作系统的模块打交道,尽量提高性能,所有的真实过程其实都是在 JVM 的 native 代码与操作系统中处理了,对我们应用程序来说,使用什么方法并没有区别。

怎么为JAVA NIO或Netty程序设置网络通信代理?

服务端

// 设置一个处理客户端消息和各种消息事件的类(Handler)bootstrap.setPipelineFactory(newChannelPipelineFactory() { @Override publicChannelPipeline getPipeline()throwsException { returnChannels.pipeline( newObjectDecoder(ClassResolvers.cacheDisabled(this .getClass().getClassLoader())), newObjectServerHandler()); }});

客户端

// 设置一个处理服务端消息和各种消息事件的类(Handler)

bootstrap.setPipelineFactory(newChannelPipelineFactory() { @Override publicChannelPipeline getPipeline()throwsException { returnChannels.pipeline(newObjectEncoder(), newObjectClientHandler()); }});

要传递对象,自然要有一个被传递模型,一个简单的Pojo,当然,实现序列化接口是必须的。

/** * @author lihzh * @alia OneCoder * @blog */public class Command implementsSerializable { privatestaticfinallongserialVersionUID = 7590999461767050471L; privateString actionName; publicString getActionName() { returnactionName; } publicvoidsetActionName(String actionName) { this.actionName = actionName; }}

服务端和客户端里,我们自定义的Handler实现如下:

ObjectServerHandler .java

/** * 对象传递服务端代码 * * @author lihzh * @alia OneCoder * @blog */public class ObjectServerHandler extendsSimpleChannelHandler { /** * 当接受到消息的时候触发 */ @Override publicvoidmessageReceived(ChannelHandlerContext ctx, MessageEvent e) throwsException { Command command = (Command) e.getMessage(); // 打印看看是不是我们刚才传过来的那个 System.out.println(command.getActionName()); }}

ObjectClientHandler .java

/** * 对象传递,客户端代码 * * @author lihzh * @alia OneCoder * @blog */public class ObjectClientHandler extendsSimpleChannelHandler { /** * 当绑定到服务端的时候触发,给服务端发消息。 * * @author lihzh * @alia OneCoder */ @Override publicvoidchannelConnected(ChannelHandlerContext ctx, ChannelStateEvent e) { // 向服务端发送Object信息 sendObject(e.getChannel()); } /** * 发送Object * * @param channel * @author lihzh * @alia OneCoder */ privatevoidsendObject(Channel channel) { Command command =newCommand(); command.setActionName("Hello action."); channel.write(command); } }

启动后,服务端正常打印结果:Hello action.

简单梳理一下思路:

通过Netty传递,都需要基于流,以ChannelBuffer的形式传递。所以,Object - ChannelBuffer.

Netty提供了转换工具,需要我们配置到Handler。

样例从客户端 - 服务端,单向发消息,所以在客户端配置了编码,服务端解码。如果双向收发,则需要全部配置Encoder和Decoder。

这里需要注意,注册到Server的Handler是有顺序的,如果你颠倒一下注册顺序:

bootstrap.setPipelineFactory(newChannelPipelineFactory() {

@Override publicChannelPipeline getPipeline()throwsException { returnChannels.pipeline(newObjectServerHandler(), newObjectDecoder(ClassResolvers.cacheDisabled(this .getClass().getClassLoader())) ); }});

结果就是,会先进入我们自己的业务,再进行解码。这自然是不行的,会强转失败。至此,你应该会用Netty传递对象了吧。

hbase与客户端的通信过程解析

hbase通信主要涵盖了两个技术,一个是 google的protobuf rpc通信框架 ,一个是 java的NIO通信 ;

org.apache.hadoop.hbase.regionserver.HRegionServer这个类是regionserver的启动类;

org.apache.hadoop.hbase.master.HMaster这个类是Hmaster的启动类,继承了HRegionServer;

而HRegionServer定义了一个org.apache.hadoop.hbase.regionserver.RSRpcServices变量:

因此整个通信过程最核心的就是这两个类:RSRpcServices和RpcServer

hbase的protobuf的使用流程如下:

此过程主要是以下要讨论的 JAVA NIO做的工作;

Message callBlockingMethod(MethodDescriptor var1, RpcController var2, Message var3) throws ServiceException;

关于 java NIO的使用,主要集中于RpcServer类中:

主要使用了一个listener,但是实际情况这不是一个常见的listener模式,而是用来监听请求的监听器。

而它的实现如下:

主要定义了一个acceptChannel,一个selector和多个readers,每个reader对应一个selector;

它的主线程是监控selector中的accept请求,进行doAccept操作:

主要是对每个accept请求创建了一个connection对象,每个connection对应一个读写数据的channel,然后注册channel给某一个reader的selector;

对于每个reader线程来说,会对自己selector绑定的所有的SelectionKey进行查看,如果接收到数据,那么对绑定的connection进行处理,最后调用connection的process方法;

解析收到的请求,然后创建请求;通过scheduler执行,

scheduler是整个regionserver处理所有请求的核心,创建scheduler需要用到参数如下,因此hbase.regionserver.handler.count参数决定了同时进行处理请求的handler个数,即regionserver的并发能力。

最后再rpcserver中调用call函数:

Message result = service.callBlockingMethod(md, controller, param);

上边写到数据的具体执行在CallRunner中,执行结束后调用Call.setResponse方法,

其中通过IPCUtil.getDelimitedMessageAsByteBuffer(result)把messgae数据序列化成buffer,调用google提供的com.google.protobuf.CodedOutputStream实现的序列化方法。

以下是reponder提供的方法:

最后将数据写进属于自己的channel中。

java的nio异步通信的原理

感谢你的问题 我简单的学习了一下

Java IO的各种流是阻塞的。这意味着,当一个线程调用read() 或 write()时,该线程被阻塞,直到有一些数据被读取,或数据完全写入。该线程在此期间不能再干任何事情了。 Java NIO的非阻塞模式,使一个线程从某通道发送请求读取数据,但是它仅能得到目前可用的数据,如果目前没有数据可用时,就什么都不会获取。而不是保持线程阻塞,所以直至数据变的可以读取之前,该线程可以继续做其他的事情。 非阻塞写也是如此。一个线程请求写入一些数据到某通道,但不需要等待它完全写入,这个线程同时可以去做别的事情。 线程通常将非阻塞IO的空闲时间用于在其它通道上执行IO操作,所以一个单独的线程现在可以管理多个输入和输出通道(channel)。

希望能帮到你

关于javanio通信和java系统间通信的介绍到此就结束了,不知道你从中找到你需要的信息了吗 ?如果你还想了解更多这方面的信息,记得收藏关注本站。