java - 打开多个 InputStream 的优缺点？

Question

编码时the solution downloading a huge dynamic zip with low RAM impact的问题，一个想法开始围攻我，并导致了这个问题，要求纯粹的好奇心/对知识的渴望:

如果不加载 InputStream，我会遇到什么样的缺点？一次一个(对数据库进行单独查询)，我将加载所有 InputStream s 在单个查询中，返回一个列表(n，可能有数千个，“已打开”)InputStreams ？

当前(安全)版本:n 个查询，一个 inputStream 一次实例化

for (long id : ids){
    InputStream in = getMyService().loadStreamById(id);
    IOUtils.copyStream(in, out);
    in.close();
}

假设版本:一个查询，n 个实例化的 inputStreams

List<InputStream> streams = getMyService().loadAllStreams();

for (InputStream in : streams){     
    IOUtils.copyStream(in, out);
    in.close();
    in = null;
}

第二种方法的优缺点是什么，不包括用于保持多个 java InputStream 实例化的(我想很少)内存量？

它是否会导致某种网络卡住或数据库压力(或锁定，或者如果其他人读/写 Stream 指向的相同 BLOB 字段等问题，等等...)超过多个查询？

或者他们是否足够聪明以至于在被要求提供数据之前几乎是隐形的，然后1 query + 1000 active stream可能比 1000 query + 1 active stream 更好？

Answer 1

简短的回答是，您可能会遇到操作系统和/或 DBMS 的限制。

较长的答案取决于具体的操作系统和 DBMS，但这里有几点需要考虑:

• 在 Linux 上，任何进程都可以拥有最大数量的打开文件描述符。默认值是/曾经是 1024，但增加它相对容易。这个限制 IMO 的目的是杀死一个写得不好的进程，因为每个文件/套接字所需的内存量是最小的(在现代机器上)。
• 如果打开的流表示与数据库的单个套接字连接，则单台机器可以打开到单个服务器地址/端口的客户端套接字总数有一个硬性限制。这是由客户端的动态端口地址范围驱动的，它是 16 或 32k(但可以修改)。此限制适用于机器上的所有进程，因此一个进程的过度消耗可能会使尝试访问同一服务器的其他进程饿死。
• 根据 DBMS 管理用于检索 BLOB 的连接的方式，您可能会遇到 DBMS 强制执行的小得多的限制。例如，Oracle 默认为每个用户连接总共 50 个“游标”(主动检索操作)。

除了这些限制之外，您不会从编写的代码中获得任何好处，因为它按顺序运行连接。如果您要使用多个线程来读取，您可能会看到拥有多个并发连接的一些好处。但是，我仍然会根据需要打开这些连接。为了避免您考虑为每个连接生成一个线程(并遇到线程数量的物理限制)，您可能会在达到任何物理限制之前达到实际的吞吐量限制。