如何在Java parallelStream中使用print（“\\ r”+ progressMessage）？

Question

I am trying to display a progress for my parallelStream by writing something like

int total=myList.size();
AtomicInteger counter=new AtomicInteger(0);

List<String> myResult=IntStream.range(0, total)
                    .parallel()
                    .mapToObj(i-> modify(myList.get(i)))
                    .peek(i->System.out.print("\r"+(counter.getAndIncrement()*100/total)+"%"))
                    .collect(toList());

My problem comes from the "\\r". Given that it's parallelized, the amount of "\\r" needed to really go to the beginning of the line may vary when concurrent events occur. So I can read sometimes "70% 71%"...

Answer 1

Separate the progress recording from the progress output operation:

int total = myList.size();
AtomicInteger counter = new AtomicInteger(0);
ScheduledExecutorService es = Executors.newScheduledThreadPool(1);

ScheduledFuture<?> f = es.scheduleWithFixedDelay(new Runnable() {
    int lastReported = -1;
    public void run() {
        int newValue = counter.get();
        if(newValue != lastReported) {
            lastReported = newValue;
            System.out.append("\r"+newValue*100/total+"%").flush();
        }
    }
}, 100, 100, TimeUnit.MILLISECONDS);

List<String> myResult = IntStream.range(0, total)
    .parallel()
    .mapToObj(i -> modify(myList.get(i)))
    .peek(i -> counter.incrementAndGet())
    .collect(toList());

f.cancel(true);
es.shutdown();
System.out.print("\r100%");

Now, the printing is done consistently by one thread. This separation solves even more issues. Performing a print operation for every element will slow down your actual processing significantly. By using a scheduled printing job, you can control the overhead yourself, ie you don't need printing faster than a human can read and you don't need to perform an expensive printing operation if the percentage did not change since the last update.

Note that by the time, all elements have passed the peek action, the stream operation has not entirely completed (there's at least one merge operation pending), but that's the best progress estimate you can get with the current API.