对于诸如所示的简单情况，它们基本上是相同的。但是，有许多细微的差异可能很重要。

一个问题是订购。使用Stream.forEach，顺序不确定。顺序流不太可能发生，但仍可以按Stream.forEach任意顺序执行。这确实在并行流中经常发生。相反，如果指定，Iterable.forEach则总是以的迭代顺序执行Iterable。

另一个问题是副作用。Stream.forEach必须指定中的动作为非干扰动作。（请参阅java.util.stream软件包doc。）Iterable.forEach可能会有更少的限制。对于中的集合java.util，Iterable.forEach通常将使用该集合的Iterator，其中大多数被设计为快速失败的，并且ConcurrentModificationException如果在迭代过程中对结构进行了修改，则会抛出该集合。但是，在迭代过程中允许进行非结构化的修改。例如，ArrayList类文档说“仅设置元素的值不是结构修改”。因此，针对ArrayList.forEach允许在底层中设置值ArrayList而不会出现问题。

并发集合又一次不同。它们不是快速失败，而是设计为弱一致性。完整的定义在该链接上。不过，请简要考虑一下ConcurrentLinkedDeque。传递给其forEach方法的操作被允许修改底层双端队列，即使在结构上ConcurrentModificationException也是如此，并且永远不会抛出该异常。但是，发生的修改在此迭代中可能可见，也可能不可见。（因此保持“弱”一致性。）

如果Iterable.forEach正在同步的集合上进行迭代，则仍然可以看到另一个差异。在这样的集合上，Iterable.forEach 获取一次该集合的锁，并在对action方法的所有调用中保持该锁。该Stream.forEach调用使用集合的分隔符，该分隔符不会锁定，并且依赖于不干扰的流行规则。支持该流的集合可以在迭代期间进行修改，如果是，则ConcurrentModificationException可能导致行为不一致或行为不一致。