我有一个Record
课程:
public class Record implements Comparable<Record>
{
private String myCategory1;
private int myCategory2;
private String myCategory3;
private String myCategory4;
private int myValue1;
private double myValue2;
public Record(String category1, int category2, String category3, String category4,
int value1, double value2)
{
myCategory1 = category1;
myCategory2 = category2;
myCategory3 = category3;
myCategory4 = category4;
myValue1 = value1;
myValue2 = value2;
}
// Getters here
}
我创建了很多记录的大清单。只有第二个和第五个值i / 10000
和i
稍后会被吸气剂getCategory2()
和getValue1()
使用。
List<Record> list = new ArrayList<>();
for (int i = 0; i < 115000; i++)
{
list.add(new Record("A", i / 10000, "B", "C", i, (double) i / 100 + 1));
}
请注意,前10,000个记录的category2
为0
,接下来的10,000个记录为1
等,而value1
值依次为0-114999。< / p>
我创建的Stream
同时为parallel
和sorted
。
Stream<Record> stream = list.stream()
.parallel()
.sorted(
//(r1, r2) -> Integer.compare(r1.getCategory2(), r2.getCategory2())
)
//.parallel()
;
我有一个ForkJoinPool
维护8
个线程,这是我在PC上拥有的核心数。
ForkJoinPool pool = new ForkJoinPool(8);
List<Record> output = pool.submit(() ->
stream.collect(Collectors.toList()
)).get();
我希望并行sorted
操作会尊重流的遭遇顺序,并且它将是 stable 排序,因为Spliterator
返回ArrayList
1}}是ORDERED
。
但是,按顺序打印出结果List
output
的元素的简单代码表明情况并非如此。
for (Record record : output)
{
System.out.println(record.getValue1());
}
输出,浓缩:
0
1
2
3
...
69996
69997
69998
69999
71875 // discontinuity!
71876
71877
71878
...
79058
79059
79060
79061
70000 // discontinuity!
70001
70002
70003
...
71871
71872
71873
71874
79062 // discontinuity!
79063
79064
79065
79066
...
114996
114997
114998
114999
size()
的{{1}}为output
,所有元素都显示在那里,只是顺序略有不同。
所以我写了一些检查代码,看看115000
是否稳定。如果它稳定,则所有sort
值应保持有序。此代码验证订单,打印任何差异。
value1
输出:
int prev = -1;
boolean verified = true;
for (Record record : output)
{
int curr = record.getValue1();
if (prev != -1)
{
if (prev + 1 != curr)
{
System.out.println("Warning: " + prev + " followed by " + curr + "!");
verified = false;
}
}
prev = curr;
}
System.out.println("Verified: " + verified);
如果我执行以下任何操作,此情况仍然存在:
将Warning: 69999 followed by 71875!
Warning: 79061 followed by 70000!
Warning: 71874 followed by 79062!
Warning: 99999 followed by 100625!
Warning: 107811 followed by 100000!
Warning: 100624 followed by 107812!
Verified: false
替换为ForkJoinPool
。
ThreadPoolExecutor
通过直接处理ThreadPoolExecutor pool = new ThreadPoolExecutor(8, 8, 0, TimeUnit.SECONDS, new ArrayBlockingQueue<>(10));
来使用公共ForkJoinPool
。
Stream
在致电List<Record> output = stream.collect(Collectors.toList());
后致电parallel()
。
sorted
致电Stream<Record> stream = list.stream().sorted().parallel();
而非parallelStream()
。
stream().parallel()
使用Stream<Record> stream = list.parallelStream().sorted();
排序。请注意,此排序标准与我为Comparator
接口定义的“自然”顺序不同,尽管从结果开始按结果开始,但结果应该仍然相同。
Comparable
如果我不在Stream<Record> stream = list.stream().parallel().sorted(
(r1, r2) -> Integer.compare(r1.getCategory2(), r2.getCategory2())
);
上执行以下操作之一,我只能保留遭遇顺序:
Stream
。parallel()
的任何重载。有趣的是,没有排序的sorted
保留了订单。
在上述两种情况中,输出为:
parallel()
我的Java版本是1.8.0_05。这个异常也是occurs on Ideone,似乎运行Java 8u25。
更新
我将JDK升级到撰写本文时的最新版本1.8.0_45,问题没有改变。
问题
结果Verified: true
(List
)中的记录顺序是否不按顺序排序,因为排序在某种程度上不稳定,因为不会保留遭遇顺序或其他原因?
如何在创建并行流并对其进行排序时确保保留遭遇顺序?
答案 0 :(得分:11)
看起来Arrays.parallelSort
在某些情况下并不稳定。好眼力。流并行排序是以Arrays.parallelSort
实现的,因此它也会影响流。这是一个简单的例子:
public class StableSortBug {
static final int SIZE = 50_000;
static class Record implements Comparable<Record> {
final int sortVal;
final int seqNum;
Record(int i1, int i2) { sortVal = i1; seqNum = i2; }
@Override
public int compareTo(Record other) {
return Integer.compare(this.sortVal, other.sortVal);
}
}
static Record[] genArray() {
Record[] array = new Record[SIZE];
Arrays.setAll(array, i -> new Record(i / 10_000, i));
return array;
}
static boolean verify(Record[] array) {
return IntStream.range(1, array.length)
.allMatch(i -> array[i-1].seqNum + 1 == array[i].seqNum);
}
public static void main(String[] args) {
Record[] array = genArray();
System.out.println(verify(array));
Arrays.sort(array);
System.out.println(verify(array));
Arrays.parallelSort(array);
System.out.println(verify(array));
}
}
在我的机器上(2核x 2线程)打印以下内容:
true
true
false
当然,它应该打印true
三次。这是在当前的JDK 9开发版本上。如果它发生在迄今为止的所有JDK 8版本中,鉴于您已经尝试过,我不会感到惊讶。奇怪的是,减小大小或除数会改变行为。大小为20,000,除数为10,000是稳定的,大小为50,000,除数为1,000也是稳定的。看起来这个问题与比较相等和平行分割尺寸的足够大的值运行有关。
OpenJDK问题JDK-8076446涵盖了这个错误。