blocks|key|1640420|text|通常情况下，accumulator是一个英文单词，意思是：“如果你想要并行性的话，你会被完全冲洗”。它就在这个词里:积累--随着时间的推移而聚集。没有正确的方法，除非从一开始，并应用积累，直到你完成。|type|unstyled|depth|inlineStyleRanges|offset|length|style|CODE|entityRanges|data|1640421|但是，java通过添加两个需求来解决这一问题：|1640422|1640423|associativity.function.|ordered-list-item|1640424|identity必须产生与(a+X+b)+X+c相同的结果，其中X是累加器(a+X+b)+X+c函数。ident+X+a必须等于a，其中ident是传递给reduce的标识，X是累加器函数。|1640425|1640426|让我们以函数(a,+b)+->+a+%2B+b和identity+0为例，如果您的目的是对一个列表进行求和，它就满足了这两个要求。|1640427|Java只需对任意项进行求和，然后对这些项的结果进行求和，就可以将其并行化。[1,+5,+9,+12]可以先将列表合并为两个，然后将这两个子列表分别交给线程进行求和，然后将每个线程提供的答案相加。--这意味着java将在流中的任意点开始多次积累，并将标识作为其累积的一部分应用于任意点(任意点)，如果标识对象本身是可变的，则会带来迅速的问题。|BOLD|1640428|基本上没有办法将可变的identity对象和java的reduce函数的概念结合起来。从根本上来说，它的设计并不是为了这样做的。|1640429|与求和示例相反:没有修改(a,+b)+->+a+%2B+b累加器中的a，也没有修改b；相反，它们被组合成一个新创建的第三个值，这就是您应该如何使用这个方法。|1640430|与来自某些其他语言的foldLeft形成对比，后者既不要求accumulatorFunction(ident,+A)等于A，也不要求结合性，但根据定义，它根本不能并行化。foldLeft可以与可变状态一起使用。例如，下面是使用foldLeft+(伪代码)求和的一个推动力：(请注意，这里new+int[1]作为可变整数使用)：|1640431|int+sum+=+stream.foldLeft(new+int[1],+(int[]+a,+int+b)+->+a[0]+%2B=+b)[0];|code-block|syntax|javascript|1640432|这个概念(您的累加器函数的LHS总是相同的东西，即您的标识对象，在您沿着流移动时被修改为集成流中的每个值)是不兼容和java的缩减，而且据我所知，java没有(容易)的方法来对流进行这种操作。|1640433|这样就更糟了！‘线程安全’还不够好，它需要是不可变的。一旦它是不可变的，它就是线程安全的。|1640434|1640435|是否足以使identity对象不可变，并在每个reduce上返回一个新实例？|blockquote|1640436|1640437|1640438|这不仅仅是“足够好”，这或多或少是使用reduce的唯一明智的方式。|1640439|entityMap^0|6|B|0|0|0|0|D|B|11|B|1F|9|1S|1|1W|5|25|6|0|0|6|F|V|1|0|12|D|2Q|1C|0|B|8|R|6|0|C|F|0|A|8|T|T|3Z|A|0|0|1I|3|0|0|0|0|0|0|J|6|0^^$0|@$1|2|3|4|5|6|7|1I|8|@$9|1J|A|1K|B|C]]|D|@]|E|$]]|$1|F|3|G|5|6|7|1L|8|@]|D|@]|E|$]]|$1|H|3|-4|5|6|7|1M|8|@]|D|@]|E|$]]|$1|I|3|J|5|K|7|1N|8|@]|D|@]|E|$]]|$1|L|3|M|5|K|7|1O|8|@$9|1P|A|1Q|B|C]|$9|1R|A|1S|B|C]|$9|1T|A|1U|B|C]|$9|1V|A|1W|B|C]|$9|1X|A|1Y|B|C]|$9|1Z|A|20|B|C]]|D|@]|E|$]]|$1|N|3|-4|5|6|7|21|8|@]|D|@]|E|$]]|$1|O|3|P|5|6|7|22|8|@$9|23|A|24|B|C]|$9|25|A|26|B|C]]|D|@]|E|$]]|$1|Q|3|R|5|6|7|27|8|@$9|28|A|29|B|C]|$9|2A|A|2B|B|S]]|D|@]|E|$]]|$1|T|3|U|5|6|7|2C|8|@$9|2D|A|2E|B|C]|$9|2F|A|2G|B|C]]|D|@]|E|$]]|$1|V|3|W|5|6|7|2H|8|@$9|2I|A|2J|B|C]]|D|@]|E|$]]|$1|X|3|Y|5|6|7|2K|8|@$9|2L|A|2M|B|C]|$9|2N|A|2O|B|C]|$9|2P|A|2Q|B|C]]|D|@]|E|$]]|$1|Z|3|10|5|11|7|2R|8|@]|D|@]|E|$12|13]]|$1|14|3|15|5|6|7|2S|8|@$9|2T|A|2U|B|S]]|D|@]|E|$]]|$1|16|3|17|5|6|7|2V|8|@]|D|@]|E|$]]|$1|18|3|-4|5|6|7|2W|8|@]|D|@]|E|$]]|$1|19|3|1A|5|1B|7|2X|8|@]|D|@]|E|$]]|$1|1C|3|-4|5|6|7|2Y|8|@]|D|@]|E|$]]|$1|1D|3|-4|5|6|7|2Z|8|@]|D|@]|E|$]]|$1|1E|3|1F|5|6|7|30|8|@$9|31|A|32|B|C]]|D|@]|E|$]]|$1|1G|3|-4|5|6|7|33|8|@]|D|@]|E|$]]]|1H|$]]

Ordinarily, <code>accumulator</code> is an english word that means: &quot;You are completely hosed if you want parallelism&quot;. It's right there in the word: To accumulate - to gather over time. There is no way to do it right except to start from the beginning, and apply accumulation until you are done.
But, java gets around this by adding 2 requirements:
<ol>
<li>associativity. <code>a X (b X c)</code> must produce the same result as <code>(a X b) X c</code>, where X is the accumulator function.</li>
<li>identity function. <code>ident X a</code> must be equal to <code>a</code>, where <code>ident</code> is the identity you pass to <code>reduce</code> and X is the accumulator function.</li>
</ol>
Let's use as example the function <code>(a, b) -&gt; a + b</code> and as identity <code>0</code>, which fulfills both of these requirements if your intent is to sum a list.
Java can parallellize this by just summing arbitrary terms and then summing the results of these. <code>[1, 5, 9, 12]</code> can be summed by first lopping the list into two, then handing these 2 sublists to threads to individually sum, and then summing the answers each thread provides. This implies that java will start accumulation multiple times at arbitrary points in the stream, and will apply identity as part of its accumulation any number of times, at arbitrary points, and that brings swift problems if your identity object is itself mutable.
There's basically no way to combine the notion of a mutable <code>identity</code> object and java's <code>reduce</code> function. It is fundamentally not designed to work that way.
Contrast to the sum example: Instead of modifying a in the <code>(a, b) -&gt; a + b</code> accumulator, neither a nor b are modified; instead, they are combined into a newly created third value, and that's how you should use this method.
Contrast to <code>foldLeft</code> from certain other languages, which do not require either <code>accumulatorFunction(ident, A)</code> to be equal to A, nor associativity, but then cannot by definition parallellize it, at all. That foldLeft can be used with mutable state. For example, here is an impl of summing using a foldLeft, in pseudocode: (note that <code>new int[1]</code> is used here as mutable integer):
<pre><code>int sum = stream.foldLeft(new int[1], (int[] a, int b) -&gt; a[0] += b)[0];
</code></pre>
This notion (where the LHS of your accumulator function is always the same thing, namely, your identity object, being modified to integrate each value in the stream as you move along it) is not compatible with java's reduce, and as far as I can recall, java has no (easy) way to do this kind of thing to a stream.
Thus: It's worse! 'thread safe' isn't good enough, it needs to be immutable. Once it is immutable, it is trivially thread safe.
<blockquote>
is it enough just to make identity object immutable and return a new instance upon each reduce?
</blockquote>
That's not just 'good enough', that's more or less the only sane way to use <code>reduce</code>.

blocks|key|1090596|text|这是文档所涵盖的，但不是直接的，而是隐含的。|type|unstyled|depth|inlineStyleRanges|entityRanges|data|1090597|1090598|标识值必须是累加器函数的标识。这意味着对于所有的t，accumulator.apply(恒等式，t)等于t。|blockquote|offset|length|style|BOLD|1090599|1090600|1090601|就像您说的那样，一旦identity被修改，即使是以线程安全的方式，上面的规则也会被违反；因此无法保证预期的结果。|CODE|1090602|对于第二个问题，答案涉及得更多一些。您不必使identity不可变，只要没有人滥用它(通过修改它的内部状态)。当然，immutable在这方面有很大的帮助。|1090603|entityMap^0|0|0|F|12|0|0|0|A|8|0|M|8|1M|9|0^^$0|@$1|2|3|4|5|6|7|S|8|@]|9|@]|A|$]]|$1|B|3|-4|5|6|7|T|8|@]|9|@]|A|$]]|$1|C|3|D|5|E|7|U|8|@$F|V|G|W|H|I]]|9|@]|A|$]]|$1|J|3|-4|5|6|7|X|8|@]|9|@]|A|$]]|$1|K|3|-4|5|6|7|Y|8|@]|9|@]|A|$]]|$1|L|3|M|5|6|7|Z|8|@$F|10|G|11|H|N]]|9|@]|A|$]]|$1|O|3|P|5|6|7|12|8|@$F|13|G|14|H|N]|$F|15|G|16|H|N]]|9|@]|A|$]]|$1|Q|3|-4|5|6|7|17|8|@]|9|@]|A|$]]]|R|$]]

This is covered by the documentation, but not directly, it is implied.
<blockquote>
The identity value must be an identity for the accumulator function. This means that for all t, accumulator.apply(identity, t) is equal to t.
</blockquote>
As soon as <code>identity</code> is modified, like you say, even if in a thread-safe way, the rule above is violated; thus no guarantees of the expected result.
For the second question the answer is slightly more involved. You do not have to make the <code>identity</code> immutable, as long as no one abuses that (by modifying its internal state). Of course making it <code>immutable</code> helps a lot in that regard.

Java stream API offers a general <code>.reduce(identity, accumulator)</code> method.
It is pretty clear from javadocs that accumulator should be a stateless function.
However, I have a question about the <code>identity</code> object, namely should it be thread-safe?
Lets say an <code>identity</code> is a java object and an <code>accumulator</code> modifies that object in a way that the modification is not atomic, e.g. <code>accumulator</code> looks into <code>identity's</code> state and then decides how to modify it's internal state exactly. Clearly it can happen that several reduce operations may run at the same time. In this case several questions arise:
<ul>
<li>should this one reduce operation be atomic in the scope of the <code>identity</code> object?</li>
<li>is it enough just to make <code>identity</code> object immutable and return a new instance upon each reduce?</li>
</ul>

How to make stream reduce be thread safe?

翻译质量差，导致语言生硬或混乱。

没有提供实际的解决方法或示例。

解答不清晰，无法理解或解决问题。

页面排版不美观，阅读体验差。

文章

问答

视频

学习中心

腾讯云实验室

直播

竞赛

腾讯云代码分析专区

腾讯iOA零信任安全管理系统专区

腾讯云架构师技术同盟交流圈

腾讯云数据库专区

腾讯云顾问专区

腾讯云原生专区

腾讯混元专区

腾讯云TCE专区

腾讯云Lighthouse专区

腾讯云HAI专区

腾讯云Edgeone专区

腾讯云存储专区

腾讯云智能专区

腾讯轻联专区 

腾讯云开发专区

TAPD专区

腾讯轻量云游戏服专区

腾讯云最具价值专家

腾讯云架构师技术同盟

腾讯云创作之星

腾讯云开发者先锋

腾讯云代码助手

云原生构建

TAPD 敏捷项目管理

Cloud Studio

SDK中心

API中心

命令行工具

涵盖代码开发、场景应用、自动测试全流程，助你从零构建专属AI助手

一站式MCP教程库，解锁AI应用新玩法

Java提供了一个通用的.reduce(identity, accumulator)方法。从javadocs中可以很清楚地看出，累加器应该是一个无状态函数。但是，我有一个关于identity对象的问题，即它应该是线程安全的吗？让我们假设一个identity是一个java对象，而一个accumulator以一种非原子化的...

问如何使流减少线程安全？
EN

Stack Overflow用户

社区

活动

圈层

关于

腾讯云开发者

热门产品

热门推荐

更多推荐

问如何使流减少线程安全？EN