当我们向流API提供一些输入时,它将其分成块,JVM创建多个线程以在该块上执行执行.
题 :-
如果我给出了数百万个条目ArrayList作为并行管道的输入,并且在List by JVM上的计算的前半部分之后发生内部线程异常.
JVM如何处理ROll Back.
JVM真的回滚到了原始状态吗？
没有回滚的东西,在正常情况下,没有必要这样做.流操作正在从源读取并生成新结果.在异常的情况下,没有新结果,并且在处理期间创建的任何临时对象最终将被垃圾收集.
在一个完美的世界中,终端操作会在将异常转发给调用者之前等待所有子任务的完成,但是目前它还没有,请参阅此问答.但即使它确实如此,子任务继续处理项目,直到他们的工作量结束或检测到操作已中止,而不是回滚他们以前的工作.
请注意,文档明确不鼓励使用具有有状态行为的函数,因为在使用并行流时结果可能是不确定的或不正确的.即使没有例外,并行流也可以处理在执行短路操作时对最终结果没有贡献的元素.在任何一种情况下,功能产生的副作用都不能回滚.
必须强调的是,这也适用于副作用的合法使用,即使用peek或forEach在特殊情况下不会撤消其行为.如果您peek出于预期目的使用,那么这不是问题,因为报告元素已被处理仍然是正确的,即使结果因后续异常而被删除.如果这是你的行动传递到一个问题forEach,因为你不希望他们发生在特殊情况下,有没有办法解决第1集合中的元素,例如通过toArray或collect(toList()),并做了forEach之后流操作的结果正常完成.
当然,如果动作只修改具有自己的回滚机制的某些事物的状态,例如将每个元素发送到数据库,则不需要这样做.
对于一些情况下,读取操作的流并当修改源,例如状态从一个随机数发生器读取的数字,从线BufferedReader,或从一个令牌Scanner(爪哇9) .在这些情况下,操作也会对无法撤消的源产生影响.
在的情况下,BufferedReader.lines()和Scanner.tokens(),文件明确指出,阅读器/扫描仪是在手术后未指定状态,即使在非特殊情况下,以及Random数发生器通常喜欢反正生产不可预知的数字处理.因此,对于这些情况都没有,没有回滚会导致问题.
| 归档时间： |
|
| 查看次数： |
113 次 |
| 最近记录： |