ILock Interface

Definição

[Android.Runtime.Register("java/util/concurrent/locks/Lock", "", "Java.Util.Concurrent.Locks.ILockInvoker")]
public interface ILock : Android.Runtime.IJavaObject, IDisposable, Java.Interop.IJavaPeerable

[<Android.Runtime.Register("java/util/concurrent/locks/Lock", "", "Java.Util.Concurrent.Locks.ILockInvoker")>]
type ILock = interface
    interface IJavaObject
    interface IDisposable
    interface IJavaPeerable

Derivado

Java.Util.Concurrent.Locks.ReentrantLock

Java.Util.Concurrent.Locks.ReentrantReadWriteLock.ReentrantReadLock

Java.Util.Concurrent.Locks.ReentrantReadWriteLock.ReentrantWriteLock

Atributos

RegisterAttribute

Implementações

IJavaObject IJavaPeerable IDisposable

Comentários

Lock as implementações fornecem operações de bloqueio mais abrangentes do que podem ser obtidas usando synchronized métodos e instruções. Elas permitem estruturação mais flexível, podem ter propriedades bem diferentes e podem dar suporte a vários objetos associados Condition .

Um bloqueio é uma ferramenta para controlar o acesso a um recurso compartilhado por vários threads. Normalmente, um bloqueio fornece acesso exclusivo a um recurso compartilhado: apenas um thread por vez pode adquirir o bloqueio e todo o acesso ao recurso compartilhado requer que o bloqueio seja adquirido primeiro. No entanto, alguns bloqueios podem permitir acesso simultâneo a um recurso compartilhado, como o bloqueio de leitura de um ReadWriteLock.

O uso de synchronized métodos ou instruções fornece acesso ao bloqueio de monitor implícito associado a cada objeto, mas força que toda a aquisição e liberação de bloqueio ocorram de forma estruturada em bloco: quando vários bloqueios são adquiridos, eles devem ser liberados na ordem oposta e todos os bloqueios devem ser liberados no mesmo escopo lexical no qual foram adquiridos.

Embora o mecanismo de escopo para synchronized métodos e instruções torne muito mais fácil programar com bloqueios de monitor e ajuda a evitar muitos erros comuns de programação envolvendo bloqueios, há ocasiões em que você precisa trabalhar com bloqueios de maneira mais flexível. Por exemplo, alguns algoritmos para percorrer estruturas de dados acessadas simultaneamente exigem o uso de &aspas; hand-over-hand" ou > chain locking": você adquire o bloqueio do nó A, depois o nó B, em seguida, libera A e adquire C, em seguida, libera B e adquire D e assim por diante. As implementações da Lock interface permitem o uso dessas técnicas permitindo que um bloqueio seja adquirido e liberado em escopos diferentes, permitindo que vários bloqueios sejam adquiridos e liberados em qualquer ordem.

Com essa maior flexibilidade vem a responsabilidade adicional. A ausência de bloqueio estruturado em bloco remove a liberação automática de bloqueios que ocorrem com synchronized métodos e instruções. Na maioria dos casos, o seguinte idioma deve ser usado:

{@code
            Lock l = ...;
            l.lock();
            try {
              // access the resource protected by this lock
            } finally {
              l.unlock();
            }}

Quando o bloqueio e o desbloqueio ocorrem em escopos diferentes, deve-se tomar cuidado para garantir que todo o código executado enquanto o bloqueio é mantido seja protegido por try-finally ou try-catch para garantir que o bloqueio seja liberado quando necessário.

Lock as implementações fornecem funcionalidade adicional sobre o uso de synchronized métodos e instruções fornecendo uma tentativa sem bloqueio de adquirir um bloqueio (#tryLock()), uma tentativa de adquirir o bloqueio que pode ser interrompido (#lockInterruptiblye uma tentativa de adquirir o bloqueio que pode ter tempo limite (#tryLock(long, TimeUnit)).

Uma Lock classe também pode fornecer comportamento e semântica que é bem diferente do bloqueio de monitor implícito, como ordenação garantida, uso não reentrante ou detecção de deadlock. Se uma implementação fornecer essa semântica especializada, a implementação deverá documentar essas semânticas.

Observe que Lock as instâncias são apenas objetos normais e podem ser usadas como destino em uma synchronized instrução. A aquisição do bloqueio de monitor de uma Lock instância não tem nenhuma relação especificada com a #lock invocação de nenhum dos métodos dessa instância. É recomendável que, para evitar confusão, você nunca use Lock instâncias dessa maneira, exceto dentro de sua própria implementação.

Exceto quando observado, passar um null valor para qualquer parâmetro resultará em um NullPointerException lançamento.

<Sincronização> de memória h2</h2>

Todas as Lock implementações <em devem></em> impor a mesma semântica de sincronização de memória fornecida pelo bloqueio de monitor interno, conforme descrito no Capítulo 17 do <cite>The Java Language Specification</cite>: <ul><li>Uma operação bem-sucedida lock tem os mesmos efeitos de sincronização de memória que uma ação bem-sucedida <em>Lock</em>. <li>Uma operação bem-sucedida unlock tem os mesmos efeitos de sincronização de memória que uma ação em<Desbloqueio>/em< bem-sucedida>. </ul>

Operações de bloqueio e desbloqueio malsucedidas e operações de bloqueio/desbloqueio reentrant não exigem efeitos de sincronização de memória.

<Considerações> sobre implementação h2</h2>

As três formas de aquisição de bloqueio (interruptível, não interrompível e cronometrada) podem diferir em suas características de desempenho, garantias de ordenação ou outras qualidades de implementação. Além disso, a capacidade de interromper a <>aquisição em andamento</em> de um bloqueio pode não estar disponível em uma determinada Lock classe. Consequentemente, uma implementação não é necessária para definir exatamente as mesmas garantias ou semântica para todas as três formas de aquisição de bloqueio, nem é necessária para dar suporte à interrupção de uma aquisição de bloqueio em andamento. Uma implementação é necessária para documentar claramente a semântica e as garantias fornecidas por cada um dos métodos de bloqueio. Ele também deve obedecer à semântica de interrupção, conforme definido nesta interface, na medida em que há suporte para a interrupção da aquisição de bloqueio: que é totalmente ou somente na entrada do método.

Como a interrupção geralmente implica cancelamento e verificações de interrupção geralmente são pouco frequentes, uma implementação pode favorecer a resposta a uma interrupção sobre o retorno do método normal. Isso é verdadeiro mesmo se puder ser mostrado que a interrupção ocorreu depois que outra ação pode ter desbloqueado o thread. Uma implementação deve documentar esse comportamento.

Adicionado em 1.5.

Java documentação para java.util.concurrent.locks.Lock.

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