O que é bloqueio pessimista e bloqueio otimista
A fechadura otimista corresponde às pessoas otimistas que sempre pensam que as coisas vão para melhor, e a fechadura pessimista corresponde às pessoas pessimistas que sempre pensam que as coisas vão mal. Esses dois tipos de pessoas têm suas próprias vantagens e desvantagens, e um tipo de pessoa é melhor do que o outro, dependendo da cena.
Bloqueio pessimista
Sempre suponha o pior caso. Cada vez que você obtém os dados, você acha que outros irão modificá-los, então cada vez que você obter os dados, você irá bloqueá-los, para que outros que desejam obter os dados bloqueiem até que eles obtenham o bloqueio (recurso compartilhado Ele é usado apenas por um segmento de cada vez, outros segmentos são bloqueados e os recursos são transferidos para outros segmentos após o uso). Muitos desses mecanismos de bloqueio são usados em bancos de dados relacionais tradicionais, como bloqueios de linha, bloqueios de tabela, etc., bloqueios de leitura, bloqueios de gravação, etc., que são todos bloqueados antes das operações. Bloqueios exclusivos, como synchronized e ReentrantLock em Java, são a realização da ideia de bloqueio pessimista.
Bloqueio otimista
Assuma sempre a melhor situação. Sempre que obtenho os dados, penso que outros não os modificarão, por isso não será bloqueado, mas ao atualizar, será julgado se outros atualizaram os dados durante este período. Você pode usar a versão Mecanismo de número e implementação de algoritmo CAS. O bloqueio otimista é adequado para tipos de aplicativos de leitura múltipla, o que pode melhorar o rendimento.O mecanismo write_condition semelhante ao write_condition fornecido pelo banco de dados é, na verdade, o bloqueio otimista fornecido. A classe de variável atômica no pacote java.util.concurrent.atomic em Java é implementada usando CAS, uma implementação de bloqueio otimista.
Existem também vários módulos de pontos de conhecimento para organizar documentos e perguntas de entrevistas mais reais das principais fábricas. Amigos necessitados podem clicar no link abaixo para obtê-los gratuitamente
Link: 1103806531 Senha: CSDN
Use cenários de duas fechaduras
Com a introdução acima dos dois bloqueios, sabemos que os dois bloqueios têm suas próprias vantagens e desvantagens. Um não deve ser considerado melhor do que o outro. Por exemplo, os bloqueios otimistas são adequados para menos gravações (leia mais cenários), ou seja, os conflitos são verdadeiros. Quando isso acontece raramente, isso economiza a sobrecarga do bloqueio e aumenta o rendimento geral do sistema. No entanto, se for sobrescrita, os conflitos geralmente ocorrerão com frequência, o que fará com que o aplicativo de nível superior tente novamente constantemente, o que reduzirá o desempenho, portanto, é mais apropriado usar o bloqueio pessimista no cenário de sobrescrita.
Duas implementações comuns de bloqueio otimista
O bloqueio otimista é geralmente implementado usando o mecanismo de número de versão ou algoritmo CAS.
1. Mecanismo de número de versão
Geralmente, um campo de versão do número da versão dos dados é adicionado à tabela de dados para indicar o número de vezes que os dados foram modificados. Quando os dados são modificados, o valor da versão aumentará em um. Quando o thread A deseja atualizar o valor dos dados, ele também lerá o valor da versão ao ler os dados. Ao enviar a atualização, se o valor da versão lido agora for igual ao valor da versão no banco de dados atual, ele será atualizado, caso contrário, tente novamente Operação de atualização até que a atualização seja bem-sucedida.
Dê um exemplo simples:
Supondo que haja um campo de versão na tabela de informações da conta no banco de dados, o valor atual é 1; e o campo do saldo da conta atual (saldo) é $ 100.
O Operador A lê (versão = 1) e deduz $ 50 ($ 100- $ 50) do saldo de sua conta.
Durante a operação do operador A, o operador B também lê essas informações do usuário (versão = 1) e deduz $ 20 ($ 100- $ 20) do saldo de sua conta.
O operador A conclui o trabalho de modificação, adiciona um ao número da versão dos dados (versão = 2) e envia ao banco de dados para atualização junto com o saldo de dedução da conta (saldo = $ 50). Neste momento, como a versão dos dados enviados é maior do que a versão atual do registro do banco de dados, os dados são Update, a versão do registro do banco de dados é atualizada para 2.
O operador B concluiu a operação e também aumentou o número da versão em um (versão = 2) e tentou enviar os dados para o banco de dados (saldo = $ 80), mas, neste momento, ao comparar a versão do registro do banco de dados, verificou-se que o número da versão dos dados enviados pelo operador B era 2. , A versão atual do registro do banco de dados também é 2, o que não atende à estratégia de bloqueio otimista de "a versão enviada deve ser maior que a versão atual do registro para realizar a atualização", portanto, o envio do operador B é rejeitado.
Desta forma, evita-se que o operador B substitua o resultado da operação do operador A com o resultado da modificação de dados antigos com base na versão = 1.
2. Algoritmo CAS
Nomeadamente comparar e trocar (comparar e trocar), é um algoritmo sem bloqueio bem conhecido. Programação sem bloqueio, ou seja, para obter sincronização de variáveis entre vários segmentos sem usar bloqueios, ou seja, para obter sincronização de variáveis sem bloqueio de segmentos, por isso também é chamada de sincronização sem bloqueio (Sincronização sem bloqueio).
O algoritmo CAS envolve três operandos
- Precisa ler e escrever o valor de memória V
- Valor a ser comparado A
- Novo valor a ser escrito B
Se e somente se o valor de V for igual a A, o CAS atualiza atomicamente o valor de V com o novo valor B, caso contrário nenhuma operação será realizada (comparação e substituição são uma operação atômica). Em circunstâncias normais, é uma operação de rotação, ou seja, uma nova tentativa constante.
Desvantagens do bloqueio otimista
O problema ABA é um problema comum com bloqueio otimista
1 problema ABA
Se uma variável V é o valor de A quando é lida pela primeira vez, e é verificado que ainda é o valor de A quando está pronta para ser atribuída, podemos mostrar que seu valor não foi modificado por outros threads? Obviamente, não pode, porque durante esse tempo seu valor pode ser alterado para outro valor e, em seguida, alterado de volta para A, então a operação CAS irá erroneamente acreditar que ele nunca foi modificado. Esse problema é chamado de problema "ABA" de operação do CAS.
A classe AtomicStampedReference após o JDK 1.5 fornece essa capacidade. O método compareAndSet verifica primeiro se a referência atual é igual à referência esperada e se o sinalizador atual é igual ao sinalizador esperado. Se eles forem todos iguais, a referência e o sinalizador são atomicamente O valor é definido com o valor de atualização fornecido.
2 Longo tempo de ciclo e alta sobrecarga
Spin CAS (isto é, ele será executado em um loop até que seja bem-sucedido) se não for bem-sucedido por um longo tempo, ele trará uma sobrecarga de execução muito grande para a CPU. Se a JVM puder suportar a instrução de pausa fornecida pelo processador, a eficiência será melhorada. A instrução de pausa tem duas funções. Primeiro, ela pode atrasar a execução de instruções de pipeline para que a CPU não consuma muitos recursos de execução. O tempo de atraso depende da versão de implementação específica e o tempo de atraso é zero em alguns processadores. Em segundo lugar, pode evitar o esvaziamento do pipeline da CPU causado pela violação da ordem da memória ao sair do loop, melhorando assim a eficiência de execução da CPU.
3 só pode garantir a operação atômica de uma variável compartilhada
O CAS é válido apenas para uma única variável compartilhada. O CAS é inválido quando a operação envolve várias variáveis compartilhadas. Mas desde o JDK 1.5, a classe AtomicReference é fornecida para garantir a atomicidade entre os objetos referenciados. Você pode colocar várias variáveis em um objeto para operações CAS. Portanto, podemos usar bloqueios ou usar a classe AtomicReference para compartilhar várias variáveis compartilhadas Funda em uma variável compartilhada para operar.
Use cenários de CAS e sincronizados
Simplificando, CAS é adequado para menos gravações (mais cenários de leitura, geralmente menos conflitos), sincronizado é adequado para mais gravações (mais cenários de gravação, mais conflitos em geral)
No caso de menos competição de recursos (conflitos de thread leves), o uso de bloqueios de sincronização sincronizados para bloqueio de thread e alternância de ativação, bem como operações de alternância entre o modo de usuário e o modo kernel, desperdiça recursos da CPU; o CAS é baseado no hardware e não precisa entrar no kernel Não há necessidade de trocar de thread e a chance de operar o spin é menor, portanto, um desempenho mais alto pode ser obtido.
No caso de competição séria de recursos (conflito sério de threads), a probabilidade de giro do CAS é relativamente grande, o que desperdiça mais recursos da CPU e é menos eficiente do que a sincronização.
Suplemento: A palavra-chave synchronized no campo de programação simultânea em Java sempre foi uma função veterana. Há muito tempo, muitas pessoas a chamariam de "bloqueio pesado". No entanto, após o JavaSE 1.6, ele foi incluído principalmente para reduzir o consumo de desempenho de aquisição e liberação de bloqueios, e a introdução de bloqueios de polarização e bloqueios leves, bem como várias outras otimizações, tornou-se menos importante em alguns casos. . A implementação subjacente de synchronized baseia-se principalmente em filas Lock-Free. A ideia básica é bloquear após giro e continuar a competir por bloqueios após a troca competitiva, o que sacrifica um pouco a justiça, mas atinge alto rendimento. No caso de menos conflitos de thread, desempenho semelhante ao CAS pode ser obtido e, no caso de conflitos de thread graves, o desempenho é muito superior ao CAS.
Resumindo
Devido a limitações de tempo, não está escrito em detalhes. Amigos que precisam da versão completa podem clicar no link abaixo para obtê-la gratuitamente
Link: 1103806531 Senha: CSDN
