ISpliterator Interface

Definição

[Android.Runtime.Register("java/util/Spliterator", "", "Java.Util.ISpliteratorInvoker", ApiSince=24)]
[Java.Interop.JavaTypeParameters(new System.String[] { "T" })]
public interface ISpliterator : Android.Runtime.IJavaObject, IDisposable, Java.Interop.IJavaPeerable

[<Android.Runtime.Register("java/util/Spliterator", "", "Java.Util.ISpliteratorInvoker", ApiSince=24)>]
[<Java.Interop.JavaTypeParameters(new System.String[] { "T" })>]
type ISpliterator = interface
    interface IJavaObject
    interface IDisposable
    interface IJavaPeerable

Derivado

Java.Util.Spliterators.AbstractSpliterator

Atributos

RegisterAttribute JavaTypeParametersAttribute

Implementações

IJavaObject IJavaPeerable IDisposable

Comentários

Um objeto para atravessar e particionar elementos de uma origem. A fonte de elementos cobertos por um Spliterator pode ser, por exemplo, uma matriz, um Collection, um canal de E/S ou uma função geradora.

Um Spliterator pode atravessar elementos individualmente (#tryAdvance tryAdvance()) ou sequencialmente em massa (#forEachRemaining forEachRemaining()).

Um Spliterator também pode particionar alguns de seus elementos (usando #trySplit) como outro Spliterator, para ser usado em operações possivelmente paralelas. As operações que usam um Spliterator que não pode dividir, ou o fazem de maneira altamente desequilibrada ou ineficiente, provavelmente não se beneficiarão do paralelismo. Elementos de escape transversais e de divisão; cada Spliterator é útil para apenas um único cálculo em massa.

Um Spliterator também relata um conjunto de #characteristics() sua estrutura, fonte e elementos entre #ORDERED, #DISTINCT, #SORTED, , #SIZED, #NONNULL, #IMMUTABLE, e #CONCURRENT#SUBSIZED. Estes podem ser empregados por clientes Spliterator para controlar, especializar ou simplificar a computação. Por exemplo, um Spliterator para um Collection relatório SIZED, um Spliterator para um Set relatório DISTINCTe um Spliterator para um SortedSet também relataria SORTED. As características são relatadas como um conjunto de bits unido simples.

Algumas características restringem adicionalmente o comportamento do método; por exemplo, se ORDERED, os métodos de travessia devem estar em conformidade com sua ordenação documentada. Novas características podem ser definidas no futuro, portanto, os implementadores não devem atribuir significados a valores não listados.

"binding">Um Spliterator que não reporta <c>IMMUTABLE</c> ou <c>CONCURRENT</c> deve ter uma política documentada sobre: quando o spliterator <em>se liga</em> à fonte do elemento; e detecção de interferência estrutural da fonte do elemento detectada após a ligação. Um <Spliterator em>late-binding</em> se liga à origem dos elementos no ponto de primeira travessia, primeira divisão ou primeira consulta para tamanho estimado, em vez de no momento em que o Spliterator é criado. Um Spliterator que não <é em>late-binding</em> liga-se à fonte de elementos no ponto de construção ou primeira invocação de qualquer método. As modificações feitas na fonte antes da vinculação são refletidas quando o Spliterator é atravessado. Depois de ligar um Spliterator deve, em uma base de melhor esforço, lançar ConcurrentModificationException se a interferência estrutural for detectada. Os espoliteradores que fazem isso são chamados <de fail-fast></em>. O método de travessia em massa (#forEachRemaining forEachRemaining()) de um Spliterator pode otimizar a travessia e verificar se há interferência estrutural depois que todos os elementos foram percorridos, em vez de verificar por elemento e falhar imediatamente.

Os espoliteradores podem fornecer uma estimativa do número de elementos restantes através do #estimateSize método. Idealmente, como refletido na característica #SIZED, esse valor corresponde exatamente ao número de elementos que seriam encontrados em uma travessia bem-sucedida. No entanto, mesmo quando não é exatamente conhecido, um valor estimado ainda pode ser útil para operações que estão sendo executadas na fonte, como ajudar a determinar se é preferível dividir mais ou atravessar os elementos restantes sequencialmente.

Apesar de sua utilidade óbvia em algoritmos paralelos, não se espera que os divisores sejam thread-safe; em vez disso, implementações de algoritmos paralelos usando divisores devem garantir que o divisor seja usado apenas por um thread de cada vez. Isso geralmente é fácil de obter via <em>serial thread-confinement</em>, que muitas vezes é uma consequência natural de algoritmos paralelos típicos que funcionam por decomposição recursiva. Uma chamada #trySplit() de thread pode entregar o Spliterator retornado para outro thread, que por sua vez pode atravessar ou dividir ainda mais esse Spliterator. O comportamento da divisão e da travessia é indefinido se duas ou mais roscas operarem simultaneamente no mesmo divisor. Se a rosca original entregar um divisor a outro fio para processamento, é melhor que essa transferência ocorra antes que qualquer elemento seja consumido com #tryAdvance(Consumer) tryAdvance(), pois certas garantias (como a precisão dos spliterators) só são válidas antes do início da #estimateSize()SIZED travessia.

As especializações de subtipo primitivo de Spliterator são fornecidas para OfInt int, OfLong longe OfDouble double valores. As implementações padrão do subtipo e valores primitivos de Spliterator#tryAdvance(java.util.function.Consumer) caixa para Spliterator#forEachRemaining(java.util.function.Consumer) instâncias de sua classe wrapper correspondente. Tal boxe pode minar quaisquer vantagens de desempenho obtidas com o uso das especializações primitivas. Para evitar o boxe, os métodos primitivos correspondentes devem ser usados. Por exemplo, Spliterator.OfInt#tryAdvance(java.util.function.IntConsumer) e Spliterator.OfInt#forEachRemaining(java.util.function.IntConsumer) deve ser usado em preferência a Spliterator.OfInt#tryAdvance(java.util.function.Consumer) e Spliterator.OfInt#forEachRemaining(java.util.function.Consumer). Travessia de valores primitivos usando métodos #tryAdvance tryAdvance() baseados em boxe e #forEachRemaining(java.util.function.Consumer) forEachRemaining() não afeta a ordem em que os valores, transformados em valores encaixotados, são encontrados.

Adicionado em 1.8.

Documentação Java para java.util.Spliterator.

Partes desta página são modificações baseadas no trabalho criado e compartilhado pelo Android Open Source Project e usado de acordo com os termos descritos na Creative Commons 2.5 Attribution License.

Propriedades

Métodos

Métodos de Extensão

Aplica-se a