Boas Práticas de Programação Concorrente

Transcrição

1 Boas Práticas de Programação Concorrente Evitando surpresas inconvenientes Ronny Moura

2 Súmario Principais problemas da programação concorrente e os mecanismos Java para resolvê-los. Race condition(synchronized, Lock e Atomic); Visibilidade (volatile) Exemplos de erros comuns da programação concorrente Exemplo de resolução de erro de concorrência no SIGRH.

3 Race Condition É uma condição especial que pode ocorrer dentro de uma região critica( trecho de código executado por múltiplas threads) onde a sequência da execução das threads pode ocasionar inconsistência nos valores dos recursos alterados dentro da região crítica.

4 Race Condition

5 Race Condition O código no método add() é um exemplo de uma região crítica. Como sabemos, o método não é executado de forma atomica pela JVM, ao invés é dividido em instruções, tais como ler o contador da memória dentro de um registrador, adicionar o valor para o registrador e por último escrever o registrador na memória. Agora imagine duas threads, A e B, executando add() na mesma instância de Counter.

6 Race Condition

7 Race Condition A duas threads adicionaram os valores 3 e 2 para o contador, assim era de se esperar que o valor do contador após a execução das duas threads fosse 5. No entanto, como a execução das thread é intrelaçada, o resultado é diferente.

8 Como prevenir? Para prevenir a race condition deve-se assegurar que a região crítica será executado por uma instrução atômica, ou seja, deve haver uma exclusão mútua na execução das threads dentro da região crítica. Isso implica que uma thread não executará a região crítica até a outra thread deixar a mesma. Uma estratégia eficáz para resolver o problema é o mecanismo de lock, que consiste de uma thread necessitar adquirir o lock para poder entrar na região crítica. Quando uma thread está com o lock, as outras têm que esperar a liberação do lock para que uma delas possa adquiri-lo e executar na região crítica.

9 Synchronized Java prover um mecânismo de lock por meio da palavra-chave synchronized. Existem duas formas de usar o mecânismo: sincronizando o método ou o bloco.

10 Synchronized

11 Synchronized Blocos synchronized são reentrant. Isso significa que se a thread entra em um bloco e adquire o lock para o objeto monitor do bloco( no último caso o this), então essa thread pode entrar em qualquer outro bloco que tenho o mesmo objeto monitor.

12 Synchronized

13 Lock

14 Lock (java.util.concurrent.locks) Java oferece um mecanismo mais sofisticado de lock. A interface Lock permite que o desenvolvedor implemente seu próprio mecânismo de lock mas também oferece algumas implementações.

15 Lock (java.util.concurrent.locks)

16 Lock (java.util.concurrent.locks)

17 Atomic Variable Classes A estratégia de Locking tem algumas desvantagens, a principal é o baixo desempenho, o que é mais evidente em um ambiente com muitas threads, devido ao overhead de troca de contexto e tempo de espera das threads. Uma estratégia mais eficiente em termos de desempenho é a CAS(Compare and Swap), que é uma estrátegia que exige suporte do hardware. Essa estratégia é dita non-blocking.

18 Atomic Variable Classes

19 Atomic Variable Classes As Atomic Variables Classes em Java usam a estratégia CAS. AtomicInteger, AtomicLong, AtomicBoolean e AtomicReference dispõem de métodos que garantem a atomicidade das operações. Sendo assim, essas classes são threadsafe.

20 Atomic Variable Classes

21 Atomic Variable Classes

22 Visibilidade Em um ambiente de multi-threads, muitas vezes uma thread não ver o valor atualizado de uma variável que está sendo compartilhada. Isso acontece porque, geralmente, cada thread mantém uma cópia local da váriavel, em cache, para melhorá o desempenho. Sendo assim, não é garantido que uma thread veja o valor atualizado, após a mudança na variável por uma outra thread.

23 Visibilidade Para resolver esse problema a Java oferece o modificador volatile, que garante a visibilidade correta do valor da variável compartilhada. Usar esse modificador força a JVM a usar a memória principal(não o cache local). Deve-se usar variáveis voláteis quando: Escritas na variável não depende do seu próprio valor A variável não participa do invariante com outras variáveis Não é necessário bloquear (locking) a variável por qualquer outra razão

24 Visibilidade Locking pode garantir ambas visibilidade e atomicidade, já as variáveis voláteis só podem garantir a visibilidade.

25 Visibilidade

26 Deadlock

27 Thread safe Uma classe é thread safe se ela está livre de race condition. Obs: As classes Collections não são thread-safe, no entanto na própria classe Collections existem métodos que transformam coleções non-thread-safe em coleções thread-safe.

28 Thread safe

29 Thread safe

30 Thread safe

31 Exemplos de erros comuns da programação concorrente Retirados do stackoverflow.

32 Exemplos de erros comuns da programação concorrente

33 Exemplos de erros comuns da programação concorrente

34 Exemplos de erros comuns da programação concorrente

35 Exemplos de erros comuns da programação concorrente

36 Exemplos de erros comuns da programação concorrente

37 Exemplos de erros comuns da programação concorrente

38 Exemplos de erros comuns da programação concorrente

39 Exemplos de erros comuns da programação concorrente

40 Exemplos de erros comuns da programação concorrente

41 Exemplos de erros comuns da programação concorrente

42 Exemplo de resolução de erro de concorrência no SIGRH

43 Exemplo de resolução de erro de concorrência no SIGRH

44 Exemplo de resolução de erro de concorrência no SIGRH

45 Exemplo de resolução de erro de concorrência no SIGRH

46 Referências GOETZ, Java Concurrency In Practice, Addison-Wesley Professional, Chapter 15. Atomic Variables and Non-blocking Synchronization.