我试图绕开NSOutputStream上hasSpaceAvailable背后的逻辑。
在我的应用程序中，我通过 NSInput/输出流管理的 CFSocket 发送大量数据 （100MB），这些数据分解为 4080 字节块（硬限制）。
当我开始写入数据时，大约四分之一的hasSpaceAvailable突然变得NO，所以我将数据添加到队列中。但是，如果我忽略它并尝试写入数据，则写入似乎可以工作，因为write:maxLength:的返回值与 maxLength 参数 （4080） 匹配。
输出流有什么空间？据我所知，当使用UNIX/Berkley套接字时，没有逻辑可以确定套接字是否可以写入，您只需写入并确定是否写入了所有数据。
该物业的文件指出：
一个布尔值，指示是否可以写入接收方。（只读）
YES是否可以写入接收器，或者是否必须尝试写入以确定是否有可用空间，否则NO。
在我的示例中，我看到 NO，当我仍然可以写入该套接字时，是什么因素导致了此结果。
我认为如果自上次调用写入方法以来流发送了"可用空间"流事件，则 hasSpaceAvailable 属性只会返回 YES。 你不应该轮询该属性，甚至可以说它不应该存在。 相反，您应该等待输出流上的流事件，该事件指出有可用于写入的空间。
发生该流事件时，这意味着传出数据包队列的字节数至少比套接字配置为允许您排队的最大字节数少一个字节。 换句话说，套接字上的 send（） 或 write（） 系统调用保证至少写入一个字节而不会阻塞，并且套接字保证处于非阻塞模式。
请注意，写入数据后，如果流的缓冲区可以获取更多数据（或者如果缓冲区已满，则在发送一些数据之后），流将立即发送另一个空间可用事件。