SubmissionPublisher Classe

Définition

[Android.Runtime.Register("java/util/concurrent/SubmissionPublisher", ApiSince=33, DoNotGenerateAcw=true)]
[Java.Interop.JavaTypeParameters(new System.String[] { "T" })]
public class SubmissionPublisher : Java.Lang.Object, IDisposable, Java.Lang.IAutoCloseable, Java.Util.Concurrent.Flow.IPublisher

[<Android.Runtime.Register("java/util/concurrent/SubmissionPublisher", ApiSince=33, DoNotGenerateAcw=true)>]
[<Java.Interop.JavaTypeParameters(new System.String[] { "T" })>]
type SubmissionPublisher = class
    inherit Object
    interface IAutoCloseable
    interface IJavaObject
    interface IDisposable
    interface IJavaPeerable
    interface Flow.IPublisher

Héritage

Object

JavaObject

Object

SubmissionPublisher

Attributs

RegisterAttribute JavaTypeParametersAttribute

Implémente

IJavaObject IJavaPeerable IAutoCloseable Flow.IPublisher IDisposable

Remarques

Qui Flow.Publisher émet de façon asynchrone des éléments soumis (non null) aux abonnés actuels jusqu’à ce qu’il soit fermé. Chaque abonné actuel reçoit les éléments qui viennent d’être soumis dans le même ordre, sauf si des suppressions ou des exceptions sont rencontrées. L’utilisation d’un SubmissionPublisher permet aux générateurs d’éléments d’agir en tant que serveurs de publication réactifs conformes qui s’appuient sur la gestion des suppressions et/ou le blocage pour le contrôle de flux.

Un SubmissionPublisher utilise le Executor constructeur fourni pour la remise aux abonnés. Le meilleur choix d’Exécuteur dépend de l’utilisation attendue. Si le ou les générateurs d’éléments envoyés s’exécutent dans des threads distincts et que le nombre d’abonnés peut être estimé, envisagez d’utiliser un Executors#newFixedThreadPool. Sinon, envisagez d’utiliser la valeur par défaut, normalement le ForkJoinPool#commonPool.

La mise en mémoire tampon permet aux producteurs et aux consommateurs de fonctionner temporairement à des taux différents. Chaque abonné utilise une mémoire tampon indépendante. Les mémoires tampons sont créées lors de la première utilisation et développées selon les besoins jusqu’au maximum donné. (La capacité appliquée peut être arrondie à la puissance la plus proche de deux et/ou limitées par la plus grande valeur prise en charge par cette implémentation.) Les appels de n’entraînent pas directement l’expansion de Flow.Subscription#request(long) request la mémoire tampon, mais la saturation des risques si les demandes non remplies dépassent la capacité maximale. La valeur par défaut de peut fournir un point de Flow#defaultBufferSize() départ utile pour choisir une capacité en fonction des taux, ressources et utilisations attendus.

Un seul SubmissionPublisher peut être partagé entre plusieurs sources. Actions dans un thread source avant de publier un élément ou d’émettre un signal <i>happen-before</i> actions suite à l’accès correspondant par chaque abonné. Toutefois, les estimations signalées du décalage et de la demande sont conçues pour être utilisées dans la surveillance, et non pour le contrôle de synchronisation et peuvent refléter des vues obsolètes ou inexactes de la progression.

Les méthodes de publication prennent en charge différentes stratégies sur la procédure à suivre lorsque les mémoires tampons sont saturées. Blocs de méthode #submit(Object) submit jusqu’à ce que les ressources soient disponibles. C’est le plus simple, mais le moins réactif. Les offer méthodes peuvent supprimer des éléments (immédiatement ou avec un délai d’expiration limité), mais fournir une occasion d’interposer un gestionnaire, puis réessayer.

Si une méthode Abonné lève une exception, son abonnement est annulé. Si un gestionnaire est fourni en tant qu’argument de constructeur, il est appelé avant l’annulation lors d’une exception dans la méthode Flow.Subscriber#onNext onNext, mais les exceptions dans les méthodes Flow.Subscriber#onSubscribe onSubscribeet Flow.Subscriber#onError(Throwable) onErrorFlow.Subscriber#onComplete() onComplete ne sont pas enregistrées ou gérées avant l’annulation. Si l’exécuteur fourni lève RejectedExecutionException (ou tout autre runtimeException ou erreur) lors d’une tentative d’exécution d’une tâche, ou qu’un gestionnaire de suppression lève une exception lors du traitement d’un élément supprimé, l’exception est réexpliquée. Dans ce cas, tous les abonnés n’auront pas reçu l’élément publié. Il est généralement recommandé de #closeExceptionally closeExceptionally le faire dans ces cas.

La méthode #consume(Consumer) simplifie la prise en charge d’un cas courant dans lequel la seule action d’un abonné consiste à demander et à traiter tous les éléments à l’aide d’une fonction fournie.

Cette classe peut également servir de base pratique pour les sous-classes qui génèrent des éléments et utiliser les méthodes de cette classe pour les publier. Par exemple, voici une classe qui publie régulièrement les éléments générés à partir d’un fournisseur. (Dans la pratique, vous pouvez ajouter des méthodes pour démarrer et arrêter la génération indépendamment, pour partager des exécuteurs entre les éditeurs, et ainsi de suite, ou utiliser un SubmissionPublisher en tant que composant plutôt qu’une superclasse.)

{@code
            class PeriodicPublisher<T> extends SubmissionPublisher<T> {
              final ScheduledFuture<?> periodicTask;
              final ScheduledExecutorService scheduler;
              PeriodicPublisher(Executor executor, int maxBufferCapacity,
                                Supplier<? extends T> supplier,
                                long period, TimeUnit unit) {
                super(executor, maxBufferCapacity);
                scheduler = new ScheduledThreadPoolExecutor(1);
                periodicTask = scheduler.scheduleAtFixedRate(
                  () -> submit(supplier.get()), 0, period, unit);
              }
              public void close() {
                periodicTask.cancel(false);
                scheduler.shutdown();
                super.close();
              }
            }}

Voici un exemple d’implémentation Flow.Processor . Il utilise des requêtes en une seule étape à son éditeur pour simplifier l’illustration. Une version plus adaptative peut surveiller le flux à l’aide de l’estimation du décalage retournée par submit, ainsi que d’autres méthodes utilitaires.

{@code
            class TransformProcessor<S,T> extends SubmissionPublisher<T>
              implements Flow.Processor<S,T> {
              final Function<? super S, ? extends T> function;
              Flow.Subscription subscription;
              TransformProcessor(Executor executor, int maxBufferCapacity,
                                 Function<? super S, ? extends T> function) {
                super(executor, maxBufferCapacity);
                this.function = function;
              }
              public void onSubscribe(Flow.Subscription subscription) {
                (this.subscription = subscription).request(1);
              }
              public void onNext(S item) {
                subscription.request(1);
                submit(function.apply(item));
              }
              public void onError(Throwable ex) { closeExceptionally(ex); }
              public void onComplete() { close(); }
            }}

Ajouté dans 9.

Java documentation pour java.util.concurrent.SubmissionPublisher.

Les parties de cette page sont des modifications basées sur le travail créé et partagé par Android Open Source et utilisées en fonction des termes décrits dans la Creative Commons 2.5 Attribution License.