Flusso parallelo Java - ordine di invocazione del metodo parallel () [chiuso]

AtomicInteger recordNumber = new AtomicInteger();
Files.lines(inputFile.toPath(), StandardCharsets.UTF_8)
     .map(record -> new Record(recordNumber.incrementAndGet(), record)) 
     .parallel()           
     .filter(record -> doSomeOperation())
     .findFirst()

Quando ho scritto questo ho assunto che i thread verranno generati solo dalla chiamata della mappa poiché il parallelo è posizionato dopo la mappa. Ma alcune righe nel file stavano ottenendo numeri di record diversi per ogni esecuzione.

Ho letto la documentazione ufficiale del flusso Java e alcuni siti Web per capire come funzionano i flussi sotto il cofano.

Alcune domande:

• Il flusso parallelo Java funziona basato su SplitIterator , che viene implementato da ogni raccolta come ArrayList, LinkedList ecc. Quando costruiamo un flusso parallelo da quelle raccolte, verrà utilizzato l'iteratore di divisione corrispondente per dividere e iterare la raccolta. Questo spiega perché il parallelismo è avvenuto al livello dell'origine di input originale (righe del file) piuttosto che al risultato della mappa (ovvero Record pojo). La mia comprensione è corretta?

• Nel mio caso, l'input è un flusso di file IO. Quale iteratore diviso verrà utilizzato?

• Non importa dove ci posizioniamo parallel()nella pipeline. La sorgente di input originale verrà sempre suddivisa e verranno applicate le operazioni intermedie rimanenti.

  In questo caso, Java non dovrebbe consentire agli utenti di posizionare operazioni parallele in qualsiasi punto della pipeline, tranne che alla fonte originale. Perché, sta dando una comprensione sbagliata per coloro che non sanno come java stream funzioni internamente. So che l' parallel()operazione sarebbe stata definita per il tipo di oggetto Stream e quindi funziona in questo modo. Ma è meglio fornire una soluzione alternativa.

• Nello snippet di codice sopra riportato, sto cercando di aggiungere un numero di riga a ogni record nel file di input e quindi dovrebbe essere ordinato. Tuttavia, voglio applicare doSomeOperation()in parallelo in quanto è una logica pesante. L'unico modo per ottenere è quello di scrivere il mio iteratore diviso personalizzato. C'è un altro modo?

Questo spiega perché il parallelismo è avvenuto a livello dell'origine di input originale (righe del file) piuttosto che al risultato della mappa (ovvero Record pojo).

L'intero flusso è parallelo o sequenziale. Non selezioniamo un sottoinsieme di operazioni da eseguire in sequenza o in parallelo.

Quando viene avviata l'operazione terminale, la pipeline del flusso viene eseguita in sequenza o in parallelo a seconda dell'orientamento del flusso su cui viene invocato. [...] Quando viene avviata l'operazione terminale, la pipeline del flusso viene eseguita in sequenza o in parallelo a seconda della modalità del flusso su cui viene invocata. stessa fonte

Come accennato, i flussi paralleli utilizzano iteratori divisi. Chiaramente, si tratta di partizionare i dati prima che le operazioni inizino a essere eseguite.

Nel mio caso, l'input è un flusso di file IO. Quale iteratore diviso verrà utilizzato?

Guardando la fonte, vedo che usa java.nio.file.FileChannelLinesSpliterator

Non importa dove posizioniamo parallel () nella pipeline. La sorgente di input originale verrà sempre suddivisa e verranno applicate le operazioni intermedie rimanenti.

Giusto. Puoi persino chiamare parallel()e sequential()più volte. L'ultimo invocato vincerà. Quando chiamiamo parallel(), lo impostiamo per lo stream restituito; e come detto sopra, tutte le operazioni vengono eseguite in sequenza o in parallelo.

In questo caso, Java non dovrebbe consentire agli utenti di posizionare operazioni parallele in qualsiasi punto della pipeline tranne che nella sorgente originale ...

Questo diventa una questione di opinioni. Penso che Zabuza offra una buona ragione per supportare la scelta dei designer JDK.

L'unico modo per ottenere è quello di scrivere il mio iteratore diviso personalizzato. C'è un altro modo?

Questo dipende dalle tue operazioni

• Se findFirst()è la tua vera operazione terminale, non dovrai nemmeno preoccuparti dell'esecuzione parallela, perché non ci saranno comunque molte chiamate doSomething()( findFirst()è un corto circuito). .parallel()infatti potrebbe causare l'elaborazione di più di un elemento, mentre findFirst()su un flusso sequenziale lo impedirebbe.

• Se l'operazione del terminale non crea molti dati, forse puoi creare i tuoi Recordoggetti utilizzando un flusso sequenziale, quindi elaborare il risultato in parallelo:

  List<Record> smallData = Files.lines(inputFile.toPath(), 
                                       StandardCharsets.UTF_8)
    .map(record -> new Record(recordNumber.incrementAndGet(), record)) 
    .collect(Collectors.toList())
    .parallelStream()     
    .filter(record -> doSomeOperation())
    .collect(Collectors.toList());

• Se la tua pipeline carica molti dati in memoria (che potrebbe essere il motivo che stai utilizzando Files.lines()), allora forse avrai bisogno di un iteratore di divisione personalizzato. Prima di andare lì, però, esaminerei altre opzioni (come salvare le linee con una colonna id per iniziare - questa è solo la mia opinione).
  Tenterei anche di elaborare i record in batch più piccoli, in questo modo:

  AtomicInteger recordNumber = new AtomicInteger();
  final int batchSize = 10;
  
  try(BufferedReader reader = Files.newBufferedReader(inputFile.toPath(), 
          StandardCharsets.UTF_8);) {
      Supplier<List<Record>> batchSupplier = () -> {
          List<Record> batch = new ArrayList<>();
          for (int i = 0; i < batchSize; i++) {
              String nextLine;
              try {
                  nextLine = reader.readLine();
              } catch (IOException e) {
                  //hanlde exception
                  throw new RuntimeException(e);
              }
  
              if(null == nextLine) 
                  return batch;
              batch.add(new Record(recordNumber.getAndIncrement(), nextLine));
          }
          System.out.println("next batch");
  
          return batch;
      };
  
      Stream.generate(batchSupplier)
          .takeWhile(list -> list.size() >= batchSize)
          .map(list -> list.parallelStream()
                           .filter(record -> doSomeOperation())
                           .collect(Collectors.toList()))
          .flatMap(List::stream)
          .forEach(System.out::println);
  }

  Questo viene eseguito doSomeOperation()in parallelo senza caricare tutti i dati in memoria. Ma nota che batchSizedovrà essere pensato.

Il design originale di Stream includeva l'idea di supportare le fasi successive della pipeline con diverse impostazioni di esecuzione parallele, ma questa idea è stata abbandonata. L'API può derivare da questo momento, ma d'altra parte, un progetto API che costringe il chiamante a prendere un'unica decisione inequivocabile per l'esecuzione parallela o sequenziale sarebbe molto più complicato.

L'attuale Spliteratorin uso Files.lines(…)dipende dall'implementazione. In Java 8 (Oracle o OpenJDK), ottieni sempre lo stesso di BufferedReader.lines(). Nei JDK più recenti, se Pathappartiene al filesystem predefinito e il set di caratteri è uno dei supportati per questa funzione, si ottiene uno Stream con Spliteratorun'implementazione dedicata , il java.nio.file.FileChannelLinesSpliterator. Se le condizioni preliminari non vengono soddisfatte, si ottiene lo stesso di BufferedReader.lines(), che si basa ancora su un Iteratorimplementato all'interno BufferedReadere racchiuso in Spliterators.spliteratorUnknownSize.

La tua attività specifica viene gestita al meglio con un'abitudine Spliteratorche può eseguire la numerazione delle righe direttamente alla fonte, prima dell'elaborazione parallela, per consentire la successiva elaborazione parallela senza restrizioni.

public static Stream<Record> records(Path p) throws IOException {
    LineNoSpliterator sp = new LineNoSpliterator(p);
    return StreamSupport.stream(sp, false).onClose(sp);
}

private static class LineNoSpliterator implements Spliterator<Record>, Runnable {
    int chunkSize = 100;
    SeekableByteChannel channel;
    LineNumberReader reader;

    LineNoSpliterator(Path path) throws IOException {
        channel = Files.newByteChannel(path, StandardOpenOption.READ);
        reader=new LineNumberReader(Channels.newReader(channel,StandardCharsets.UTF_8));
    }

    @Override
    public void run() {
        try(Closeable c1 = reader; Closeable c2 = channel) {}
        catch(IOException ex) { throw new UncheckedIOException(ex); }
        finally { reader = null; channel = null; }
    }

    @Override
    public boolean tryAdvance(Consumer<? super Record> action) {
        try {
            String line = reader.readLine();
            if(line == null) return false;
            action.accept(new Record(reader.getLineNumber(), line));
            return true;
        } catch (IOException ex) {
            throw new UncheckedIOException(ex);
        }
    }

    @Override
    public Spliterator<Record> trySplit() {
        Record[] chunks = new Record[chunkSize];
        int read;
        for(read = 0; read < chunks.length; read++) {
            int pos = read;
            if(!tryAdvance(r -> chunks[pos] = r)) break;
        }
        return Spliterators.spliterator(chunks, 0, read, characteristics());
    }

    @Override
    public long estimateSize() {
        try {
            return (channel.size() - channel.position()) / 60;
        } catch (IOException ex) {
            return 0;
        }
    }

    @Override
    public int characteristics() {
        return ORDERED | NONNULL | DISTINCT;
    }
}

E la seguente è una semplice dimostrazione di quando viene applicata l'applicazione del parallelo. L'output di peek mostra chiaramente la differenza tra i due esempi. Nota: la mapchiamata viene appena lanciata per aggiungere un altro metodo prima di parallel.

IntStream.rangeClosed (1,20).peek(a->System.out.print(a+" "))
        .map(a->a + 200).sum();
System.out.println();
IntStream.rangeClosed(1,20).peek(a->System.out.print(a+" "))
        .map(a->a + 200).parallel().sum();