问题标签 [nio]

我在 iSeries 机器 (JDK 1.5) 上运行一些 Java NIO 代码时遇到问题。基本上，代码是将文件分成文件的块部分到另一个较小的文件。相同的代码已经在其他 iSeries 机器上运行了一段时间，没有出现任何问题。这是代码片段：

这是堆栈跟踪：

... 11 更多

我做了一些调查，到目前为止的原因（父目录的文件权限、内存不足、共享内存控制 QSHRMEMCTL 关闭、使用 SAN）都被证明是不成功的。

有人对这个特殊问题有任何经验吗？

谢谢，布拉德。

我正在尝试使用异步连接实现客户端应用程序。我想知道在SocketChannel连接到服务器失败后我是否可以重用一个对象。

在这是选择循环之后，由于连接失败，我的套接字最终被选中。我想在该频道上排队另一个连接尝试，但我似乎没有做任何事情。该channel.isConnectionPending()方法始终返回 true（即使我尝试完成连接）

唯一的解决方案是摆脱这个SocketChannel并创建一个新的吗？

根据这篇文章，UDP 不会阻塞。使用（非阻塞）NIO API for UDP 有什么优势吗？还是我应该只使用更简单的“传统”io API？

您如何推荐制作一个高度可扩展的 SSL 客户端？

目前，我正在使用 plain Sockets 连接到需要非 HTTP SSL 套接字的 Apple APNS 服务器。我曾考虑使用 NIO 库，但它缺少SSLSocketChannel.

我为远程服务器创建了一个 SocketChannel，以在 Tomcat 上发送和接收消息。为了从远程计算机接收消息，我使用了一个专用于任务的线程（只有这个线程将从套接字读取，没有别的）。

当 SocketChannel 接收到一些字节时（我一直在非阻塞模式下轮询 SocketChannel 以获取新数据），我首先读取 4 个字节以获取下一条消息的长度，然后从 SocketChannel 分配并读取 x 个字节，即然后解码并重建成一条消息。

下面是我的接收线程代码：

我从 SocketChannel 收到的第一个字节很好，我成功解码了消息。但是，下次我从 SocketChannel 读取时，套接字向前跳过了大约 100 个字节，这导致读取错误的字节并将其解释为长度，从而导致所有内容都损坏。

代码有什么问题？没有其他线程正在从 SocketChannel 读取。

当我使用 Channels.newChannel(is) 从 InputStream 创建一个通道时，java 标准库返回一个 ReadableByteChannelImpl，即：

如您所见，它在第一次调用 read(ByteBuffer dst) 时会阻塞，并且永远不会再次阻塞。看：

这种奇怪行为背后的原因是什么？

此外，扩展 AbstractInterruptibleChannel 而不实际使该通道真正可中断的动机是什么？

我对 JDK7 中所有这些新的文件 I/O 类有点困惑。

假设，我有一个Path并且想要重命名它所代表的文件。当再次需要 a 时，如何指定新名称Path？

注意：为什么我需要JDK7？处理符号链接！

问题是：我必须对名称和位置在运行时已知的文件进行处理。所以，我需要的是一种安全的方法（没有特殊的副作用）来创建一些旧名称路径的新名称路径。

我正在对我正在使用的库进行一些更改。为了减少内存使用，库将其临时数据写入磁盘而不是将其保存在内存中。但是，对于我的使用场景，将其保存在内存中会更有效。它也有一些并发问题，因为它的临时文件具有常量名称，因此不能在不同的线程中同时运行（因为线程会破坏彼此的数据）。

因此，我需要更改库，以便将所有数据保存在内存中。我最初并没有编写这个库，因此我对对代码进行大刀阔斧的改变不是很舒服。因此，我希望通过尽可能少的重构来做到这一点。写入磁盘的代码非常简单。这是一个（有些简化的）示例：

块的读取非常相似（即它使用从 RandomAccessFile 获得的 FileChannel）。

感觉最简单的解决方案是如果我可以使用 FileChannel 的一些实现，它映射到内存中的一个位置而不是文件。我知道我可以使用 FileChannel 的映射方法将文件映射到内存中的某个位置。然而，情况恰恰相反。这给了我一个文件的“内存API”。我想要一个针对一些内存的 FileChannel 接口。有没有可用的实现？

是否可以将 NIO 与 System.in 一起使用？

我想以某种方式将“标准输入”视为可选频道。有没有人找到办法做到这一点？

我有一个算法，它目前分配了一个非常大的双精度数组，它经常更新和搜索。数组的大小为 N^2/2，其中 N 是算法运行的行数。为了与围绕算法的应用程序相关的目的，我还必须保留整个内容的副本。

当然，这对我的算法可以处理的行数施加了限制，因为我需要应对堆限制。到目前为止，我已经成功地要求使用该算法的人更新 -Xmx 设置以分配更多空间，并且效果很好。但是，我现在有一个真正的问题，我需要这个数组大于我可以放入内存的大小。

我已经计划改变我的算法以减轻这个大型阵列的必要性，并在该领域取得一些有希望的结果。然而，这是对流程的根本改变，需要做更多的工作才能达到我当前代码的高度抛光状态，该代码在生产中运行非常成功，并且已经运行了好几年。

所以，当我完善我的新算法时，我想延长现有算法的寿命，这意味着解决与分配我的巨大双精度数组相关的堆限制。

我的问题是处理它的最佳方法是什么？我应该使用 nio FileChannel 和 MappedByteBuffer，还是有更好的方法。如果我确实使用 nio 方法，与相同大小的内存数组相比，我应该预期会受到什么样的性能影响？

谢谢