Java.net与Java.nio的比较

Question

Java.net与Java.nio的比较

16

在什么情况下更好从java.net切换到java.nio？.net（不是微软实体）更易于理解和更为熟悉，而nio可扩展，并带有一些额外的巧妙功能。

具体而言，我需要为以下情况做出选择：我们有一个控制中心管理多个远程站点上的硬件（每个站点都有一台计算机管理多个硬件单元（收发器、TNC和转台）。我的想法是在每台计算机上编写一个服务器应用程序，作为控制中心到无线电硬件的网关，每个单元一个套接字。据我了解，NIO适用于一个服务器和多个客户端，但我的想法是一个客户端和多个服务器。

我想第三个选择是使用MINA，但我不确定是否会在简单问题上浪费太多。

每个远程服务器最多会有8个连接，全部来自同一客户端（以控制所有硬件和单独的TX/RX套接字）。单个客户端将希望同时连接到几个服务器。除了将每个服务器放在不同的端口上之外，还可以在客户端侧使用通道选择器吗？或者在客户端侧进行多线程io并以不同方式配置服务器更好？

实际上，由于远程机器只用于与其他硬件进行交互，RMI或IDL/CORBA是否更好？实际上，我只想能够发送命令并从硬件接收遥测数据，而不必制定一些应用层协议来完成。

- Nate Parsons

5个回答

10

可扩展性很可能会影响您选择的软件包。java.net将需要每个套接字一个线程。编码它将显着更容易。java.nio效率更高，但在编码过程中可能会比较棘手。

我建议您自己考虑要处理多少连接。如果相对较少（比如说，小于100），我会选择java.net。

- Jim Nelson

1

有了现代的64位操作系统，您可以拥有数十万个线程。 - Tom Hawtin - tackline

4

可以，但这并不一定是最具可伸缩性的架构应用程序的方式。 - Jim Nelson

1

问题不在于更多的套接字还是更多的线程，而在于每个套接字有多少个线程。 - Jim Nelson

@僵尸是什么意思？除了一个线程会花费你半兆字节和一个套接字会花费你几十千字节这个事实之外，它们几乎没有可比性。 - user207421

1

现在几乎没有理由从头开始编写这种类型的网络编程代码。像netty.io这样的包几乎总是能为您提供更可靠、更灵活的代码，而且代码行数比手工制作的解决方案要少。此外，使用Netty，您可以获得SSL支持，而不会使您的实现变得复杂。像Netty这样的库也几乎完全消除了“异步 vs 线程”问题，为您提供良好的性能，并仍然让您根据需要调整线程模型。

- pawstrong

0

从你所说的连接数量来看，我建议你使用java.net。实际上，没有必要使用非阻塞I/O来增加任务的复杂性。（除非你的远程系统性能不足，但那么你为什么还要在它们上面使用Java呢？）

看一下Apache's XML-RPC包。它易于使用，完全将网络部分隐藏起来，并且可以通过HTTP工作。无需担心协议问题...对于双方来说，它看起来都像方法调用。

- Jim Nelson

XML-RPC看起来很有趣，但我正在使用SE，而且我认为添加/切换到EE比甚至NIO都要复杂得多，但如果我错了请纠正我（它们是否在同一个JVM上运行？）。 - Nate Parsons

这是一个简单的库，应该可以在SE和EE中工作。正如另一位评论者所提到的，它确实存在可扩展性问题。但对于98%的情况，我认为它非常稳定。 - Jim Nelson

0

考虑到涉及的连接数量较少，java.net听起来是正确的解决方案。

其他帖子中提到使用XML-RPC。如果传输的数据量较小，则这是一个不错的选择，但是在编写传输大量数据（例如大请求/响应或频繁小量的数据）的进程间通信时，我使用基于XML的协议遇到了问题。与更优化的线路格式（例如ASN.1）相比，XML解析的成本通常高出几个数量级。

对于低容量控制应用程序，XML-RPC的简单性应该超过性能成本。对于高容量数据通信，最好使用更有效的线路协议。

- Frank Taylor

网页内容由stack overflow 提供, 点击上面的

可以查看英文原文，
原文链接

- Dan Dyer · Accepted Answer

除非你有充分的理由使用 NIO，否则请避免使用它。它并不好玩，而且可能没有你想象的那么有益。当你处理成千上万的连接时，你可能会获得更好的可伸缩性，但在较低数量下，使用阻塞 IO 可能会获得更好的吞吐量。然而，在做出决定之前，请务必进行自己的测试和测量以避免后悔。

还有一件需要考虑的事情是，如果你想使用 SSL，NIO 会使其变得非常痛苦。