DEV Community: Aline Ávila

Lidando com Concorrência em Java - Lock Pessimista

Aline Ávila — Mon, 17 Nov 2025 01:09:18 +0000

Partindo do pressuposto que concorrências acontecerão em uma aplicação multithread, nesse post vou descrever de forma simples e intuitiva o lock pessimista. Ele é um mecanismo de controle de acesso a recursos compartilhados, ou seja, quando threads simultâneas acessam o mesmo registro. 🚀

Importante entender também a estratégia de lock otimista e analisar qual se encaixa melhor no seu problema.

Concorrência

Bom, imagina uma aplicação multithread, ou seja, o mesmo recurso pode ser acessado simultaneamente por threads diferentes.

Threads são processos em paralelo que estão rodando no seu programa e cada uma pode estar "disputando" o mesmo dado.

Trazendo pra vida real, é como se você, leitor, tivesse tentando reservar a cadeira E10 da sessão de Velozes e Furiosos do dia 16/11 às 19:00 e Bento, no mesmíssimo instante, está fazendo a mesma reserva, na mesma cadeira, na mesma sessão. Ou seja, vocês estão "disputando" o mesmo recurso do banco de dados. Está aí um clássico exemplo de concorrência.

Pra resolver esse caso temos várias alternativas e uma delas é o uso de Lock.

🔒 O que é Lock Pessimista e Lock Otimista?

De maneira bastante resumida, um lock otimista assume que os conflitos são raros e o lock pessimista assume que os conflitos são comuns.

Tá, mas o que isso significa? Signfica que as estratégias são diferentes para cada um.

O Lock otimista verifica conflitos apenas na hora de atualizar o registro. Então, supondo que eu estou atualizando o registro de versão 2: se na hora de fazer o commit o lock vê que já existe a versão 3, significa que meu registro já não é o mais atual e a atualização para.

Por exemplo, se você começou a editar com versão 2, mas outra transação já criou a versão 3, sua atualização será rejeitada (muito abstrato, eu sei, escrever sobre lock não está sendo fácil, mas no próximo artigo vamos aprofundar no lock otimista).

Lock Pessimista

Aqui assumimos que os conflitos são comuns e por isso o lock pessimista "tranca" o registro.

Podemos dizer que a tentativa de fazer a mesma reserva no cinema é comum, certo? Bom... então vamos implantar um lock pessimista nesse sistema.

Isso significa que a partir de agora sempre que algum dado (a cadeira E10 da sessão de Velozes e Furiosos dia 16/11 as 19:00) estiver sendo disputado (por você e Bento) nós vamos trancar o acesso a essa linha do banco até que quem chegou primeiro finalize a operação que está tentando fazer.

A imagem abaixo mostra em alto nível como é realizado o lock.
Supondo que Bento começou a reserva primeiro, você só poderá fazer modificações (reservar) aquele assento quando Bento terminar ou desistir do processo dele.

E em Java usando JPA ficaria assim:

@Transactional
public void processarPedido(Long pedidoId) {
    // 1. A transação começa aqui. O pool de conexões nos empresta uma conexão.

    // 2. Pedimos o lock PESSIMISTIC_WRITE
    Pedido pedido = entityManager.find(
        Pedido.class,
        pedidoId,
        LockModeType.PESSIMISTIC_WRITE
    );

    // 3. O JPA traduz isso para SQL:
    // "SELECT * FROM pedidos WHERE id = ? FOR UPDATE"
    // O Banco de Dados AGORA bloqueia esta linha.

    // 4. NENHUMA outra transação pode escrever (ou ler com FOR UPDATE)
    // esta linha. Elas ficarão na fila, esperando.

    // ... fazemos nossa lógica de negócio ...
    pedido.setStatus("PROCESSADO");

    // 5. A transação faz COMMIT.
    // O lock é FINALMENTE liberado. A conexão é devolvida ao pool.
}

Importante notar aqui que o recurso mais escasso da sua aplicação não é CPU ou memória, é o pool de conexões do banco de dados. O lock pessimista segura essa conexão durante todo o tempo de vida da transação. Se a sua "lógica de negócio" for lenta (ex: chamar uma API externa), sua aplicação irá parar. Por isso é importante trabalhar na arquitetura da sua aplicação e não deixar que a transação precise ficar esperando por respostas externas.

Extras do JPA (o LockModeType)

LockModeType não é uma coisa só. A especificação JPA nos dá opções, e a escolha errada tem consequências.

PESSIMISTIC_WRITE (O Lock Exclusivo)

SQL: SELECT ... FOR UPDATE (na maioria dos dialetos).
O que faz: Impede que outras transações façam SELECT ... FOR UPDATE E impede que façam UPDATE ou DELETE. É um lock exclusivo total.
Quando usar: Este é o padrão. Você vai ler e definitivamente vai escrever na linha.

PESSIMISTIC_READ (O Lock Compartilhado... às vezes)

SQL: SELECT ... FOR SHARE (ex: PostgreSQL/MySQL 8+) ou ... LOCK IN SHARE MODE (MySQL antigo).
O que faz: Impede que outras transações façam UPDATE ou DELETE, mas permite que outras transações também leiam com PESSIMISTIC_READ.
Quando usar: Cenário mais raro. Você quer garantir que o dado não mude enquanto você lê, mas sabe que outros podem estar lendo ao mesmo tempo sem intenção de escrita.

PESSIMISTIC_FORCE_INCREMENT (O Híbrido)

O que faz: Adquire um lock pessimista (FOR UPDATE) e, além disso, força um incremento na coluna @version (a mesma usada pelo lock otimista), mesmo que você não altere nenhum outro campo.
Quando usar: Útil se você precisa invalidar caches ou "sinalizar" para sistemas otimistas que algo mudou, mas garantindo isso de forma pessimista.

Dicas Extras:

Considere configurar timeout no seu lock

Map<String, Object> properties = new HashMap<>();
// Define o timeout em milissegundos.
// "javax.persistence.lock.timeout" = 0 (não espere, falhe imediatamente)
// "javax.persistence.lock.timeout" = 5000 (espere 5 seg e lance LockTimeoutException)
properties.put("javax.persistence.lock.timeout", 5000);

Pedido pedido = entityManager.find(Pedido.class, id, LockModeType.PESSIMISTIC_WRITE, properties);

Se você optar pelo locking pessimista, sua transação deve ser cirúrgica. Ela deve ser extremamente rápida, não fazer I/O externo e ter um plano de tratamento para deadlocks (ordem de lock) e timeouts.

Links úteis 🔗

Spec Driven Development: IA como aliada do desenvolvedor

Aline Ávila — Sun, 09 Nov 2025 05:10:01 +0000

Neste post eu vou tentar te mostrar o que é o spec-driven development da maneira mais clara e acessível possível e meu intuito é que você possa aplicar alguns conceitos aí no seu código tornando seu agente de IA o seu melhor amigo 🤝🤖

🧩 A importância da especificação

Tudo começa com um bom README — ele pode (e deve) ser usado não só pela IA, mas também por seres humanos que passarem pelo seu código.

Um bom README geralmente contém:

Overview
Tech Stack
Prerequisites
Getting Started
Project Structure
Deployment

- Resources

Aqui vamos nos abster de citar ferramentas específicas, já que o Copilot chama suas instruções de instructions, enquanto o Cursor de rules — e provavelmente este artigo se tornaria obsoleto em questão de segundos se tentássemos acompanhar a terminologia de cada editor.

O que realmente importa é o conceito:
a especificação define como o seu código deve se comportar e, mais importante ainda, ela é a fonte da verdade para todos os seus agentes de IA e desenvolvedores que irão trabalhar naquele projeto.

Imagina que você é um chef de cozinha e suas especificações são o livro de receitas — aquele que você escreveu com todos os detalhes, inclusive a quantidade exata de gramas de sal que cada cozinheiro deve usar.

Pronto: esse é o desenvolvimento guiado por especificação.

Seu time de cozinha, nesse caso, são os agentes de IA — e eles irão performar exatamente de acordo com o que você especificar.

✍️ Um exemplo prático

Vamos supor que o desenvolvedor Mike está trabalhando em um novo post para este blog.

Ao mesmo tempo, a desenvolvedora Clara também está escrevendo um artigo sobre síndrome do impostor e quer publicá-lo aqui.

Foi definido que os posts do blog devem seguir uma estrutura específica:

devem conter título, descrição, categoria, tags, data e data de publicação.

Além disso, o texto deve seguir um estilo de escrita consistente:

O idioma principal é português;
Termos técnicos devem permanecer em inglês;
Códigos devem ter comentários em português;
O título deve respeitar um limite de caracteres;
Cada post pode ter no máximo 5 tags;
Existem diferentes tipos de posts — news, tutorial e explicações gerais (como este) — cada um com suas próprias regras;
E o mais importante: nenhum conteúdo do post deve ser gerado por IA.

Tudo isso é documentado em um arquivo Markdown de especificação, como por exemplo:

### File Structure Requirements

- **REQ-001**: Every blog post MUST be created as a Page Bundle in `/content/posts/[post-slug]/`
- **REQ-002**: The main content file MUST be named `index.md`
- **REQ-003**: Each post MUST include a featured image named `featured.jpg` or `featured.png`
- **REQ-004**: All post assets (images, diagrams) MUST be stored in the same folder as `index.md`
- **REQ-005**: Post slug (folder name) MUST use lowercase letters, numbers, and hyphens only

### Front Matter Requirements

- **REQ-006**: Every post MUST include the following front matter fields:
  - `title`: String (40–60 characters, title case)
  - `description`: String (120–160 characters)
  - `categories`: Array (typically `["tech"]`)
  - `tags`: Array (3–5 tags, lowercase, hyphen-separated)
  - `date`: Date (YYYY-MM-DD format)
  - `publishDate`: Date (YYYY-MM-DD format)

### Content Structure Requirements

- **REQ-010**: Every post MUST start with a Lead section using `{{</* lead */>}}` shortcode
- **REQ-011**: Posts with disclaimers or context notes MUST use `{{</* alert */>}}` shortcode
- **REQ-012**: Every post MUST include a "Resumo rápido (em 1 minuto) ✨" section with 4–6 bullet points
- **REQ-013**: Every post MUST include an "O que isso significa para você 🧭" section
- **REQ-014**: Every post MUST conclude with a "Links úteis 🔗" section with at least 3 relevant links
- **REQ-015**: Main content sections MUST use `##` (H2) headers with relevant emoji
- **REQ-016**: Subsections MUST use `###` (H3) headers

### Scope
This specification applies to:
- All blog posts published under `/content/posts/`
- Technical articles, tutorials, and opinion pieces
- Content written in Portuguese (pt-BR) for the Brazilian developer audience
- Posts using Hugo Page Bundle architecture with Blowfish theme v2.91.0
- **Structure generation only** — content creation is out of scope for AI assistance

🤖 IA + especificação = harmonia

Mike pede ao seu agente de IA para criar um novo post.
Paralelamente, Clara faz o mesmo com sua LLM preferida.

Se a especificação estiver bem documentada, cada agente saberá exatamente como e quais regras seguir, resultando em dois posts estruturados de forma idêntica — mesmo sendo criados por modelos diferentes.

Com as especificações do projeto em arquivos Markdown, Clara e Mike podem usar um prompt como este:

“Usando os arquivos contidos na pasta specs, crie um novo post com o título Spec Driven Development.
Este post será do tipo explicações gerais, com a categoria tech e as tags AI e programming.
O conteúdo será escrito por mim, portanto não escreva nenhum conteúdo, apenas configure a estrutura conforme a especificação.”

🚀 Escalando o conceito

Esse é um exemplo simples, mas o mesmo raciocínio pode ser aplicado a contextos muito mais complexos — definindo regras de negócio, estruturas de dados, validações, ou até pipelines de CI/CD que evoluem primeiro na especificação e só depois no código.

⚠️ Observaçoes importantes

Sua especificação não deve se preocupar com linguagem, framework ou ferramenta — ela apenas descreve o comportamento esperado.

No fim, Spec Driven Development é sobre escrever a documentação primeiro e codificar depois.
É sobre transformar a especificação na ponte entre humanos e IAs, garantindo clareza, consistência e previsibilidade no desenvolvimento.

E é assim que a IA deixa de ser apenas um assistente — e se torna a melhor amiga do dev. 💜

🐈 Dica extra pra quem utiliza github-copilot:

O projeto desse blog no git está especificado utilizando os arquivos de referencia que o github-copilot utiliza. Com convenções de nomeação de pastas e arquivos de acordo com a documentação oficial até a data deste post.

Caso queira pegar de exemplo, pode ficar a vontade 😉