DEV Community: Bruno Souza

Bora falar do padrão Strategy?

Bruno Souza — Tue, 10 Feb 2026 22:04:55 +0000

Se você já se pegou pensando “putz, esse if/else aqui tá crescendo demais” ou “cada nova regra quebra algo que já funcionava”, é bem provável que o padrão Strategy seja exatamente o que você está procurando.

Neste post, vamos falar:

O que é o Strategy
Qual problema ele resolve
Quando usar (e quando NÃO usar)
Exemplos práticos

O problema clássico

Imagine um sistema que precisa executar uma ação de formas diferentes dependendo do contexto:

Tipos diferentes de cálculo
Regras que mudam por ambiente (QA, prod)
Variações de comportamento por cliente, país ou feature

O caminho mais comum (e perigoso) costuma ser algo assim:

if tipo == A {
  faz isso
} else if tipo == B {
  faz aquilo
} else if tipo == C {
  faz outra coisa
}

Funciona? Funciona.
Escala? Nem um pouco 😅

Cada nova regra:

aumenta a complexidade
quebra o princípio aberto/fechado (Open/Closed)
transforma a função num monstro difícil de testar

O que é o padrão Strategy

O Strategy é um padrão de projeto comportamental que resolve exatamente esse problema.

A ideia central é simples:

Encapsular comportamentos intercambiáveis atrás de uma interface comum

Ou seja:

você define o que precisa ser feito (interface)
cria várias formas de fazer isso (strategies)
escolhe qual usar em tempo de execução

Sem if/else espalhado.
Sem acoplamento desnecessário.

Estrutura do Strategy

Conceitualmente, temos três peças:

Strategy (interface) – define o contrato
Concrete Strategies – implementações do comportamento
Context – quem usa a strategy

Visualmente:

Context -> Strategy
              ↑
   -------------------------
   |           |           |
StrategyA  StrategyB  StrategyC

Exemplo prático

Vamos imaginar um cenário simples:
cálculo de taxa.

Interface

type TaxStrategy interface {
    Calculate(value float64) float64
}

Implementações

type BrazilTax struct{}

func (b *BrazilTax) Calculate(value float64) float64 {
    return value * 0.15
}

type USATax struct{}

func (u *USATax) Calculate(value float64) float64 {
    return value * 0.08
}

Context

type Order struct {
    Tax TaxStrategy
}

func (o *Order) FinalValue(value float64) float64 {
    return value + o.Tax.Calculate(value)
}

Uso

order := Order{Tax: &BrazilTax{}}
final := order.FinalValue(100)

Trocar a regra não exige mudar o Order.
Só trocar a strategy.

Registry de strategies

Em sistemas maiores, é comum usar um registry para centralizar as strategies disponíveis:

var registry = map[string]TaxStrategy{
    "br": &BrazilTax{},
    "us": &USATax{},
}

Isso facilita:

extensão do sistema
leitura do código
configuração por ambiente ou feature

Quando usar Strategy

Use Strategy quando:

✅ Você tem variações de comportamento
✅ Essas variações crescem com o tempo
✅ Você quer eliminar if/else baseados em tipo, regra ou contexto
✅ Testabilidade é importante

Quando NÃO usar

Nem tudo precisa de Strategy 👀

Evite quando:

❌ Existe só uma implementação e nenhuma chance real de variação
❌ A abstração adiciona mais complexidade do que resolve
❌ O comportamento nunca muda

Padrão de projeto não é troféu — é ferramenta.

Erro comum ao usar Strategy

Um erro clássico é deixar a strategy conhecer o contexto errado, como ambiente:

if env == "qa" {
   // lógica especial
}

Se isso começa a aparecer, é sinal de que:

você precisa de strategies diferentes
ou de comportamentos injetáveis

Strategy boa é pura e focada em uma única responsabilidade.

Conclusão

O padrão Strategy é um dos padrões mais úteis no dia a dia, especialmente em sistemas que:

evoluem rápido
têm regras de negócio mutáveis
precisam ser fáceis de testar e manter

Se você sente que seu código está virando uma árvore de if/else, talvez não seja falta de esforço

Talvez só esteja faltando uma boa Estratégia 😉

O que é engenheiro de alta performance

Bruno Souza — Mon, 02 Dec 2024 21:04:54 +0000

Olá, Mentes Tech!

Conclui um curso muito massa hoje, me forneceu insights valiosos e também reforçou práticas do dia a dia, e que me permitiu escrever sobre o assunto.

Um engenheiro de alta performance é um profissional que se destaca por sua capacidade de entregar resultados consistentes e superiores, combinando competências técnicas, comportamentais e estratégicas. Ele não se limita a cumprir suas funções básicas, mas vai além, aplicando princípios de eficiência, inovação e qualidade em tudo o que faz.

Aqui estão algumas características de um engenheiro de alta performance:

Foco na eficiência: Busca continuamente otimizar processos, reduzir desperdícios e aumentar a produtividade, muitas vezes utilizando metodologias como Lean, Six Sigma ou Agile.
Habilidade em resolução de problemas: Analisa problemas complexos de forma estruturada, identificando causas raiz e implementando soluções eficazes.
Conhecimento atualizado: Está sempre em busca de aprendizado contínuo para acompanhar as novas tecnologias, tendências e boas práticas do setor.
Liderança e trabalho em equipe: Atua como um facilitador em projetos, colaborando e liderando equipes para alcançar objetivos comuns.
Compromisso com qualidade: Garante que os produtos, serviços ou projetos que entrega atendam ou superem os padrões esperados.
Capacidade de adaptação: Enfrenta mudanças e desafios com flexibilidade, ajustando rapidamente suas abordagens e estratégias.

Ser um engenheiro de alta performance significa integrar conhecimento técnico, visão estratégica e habilidades interpessoais para alcançar resultados extraordinários e gerar impacto positivo nas organizações.

Reference Counting vs Tracing Garbage Collection

Bruno Souza — Mon, 02 Sep 2024 18:24:00 +0000

Olá, Mentes Tech!

Você sabe o que é contagem de referência e rastreamento de referências no contexto de desalocação de memória ?

A diferença entre rastreamento de referências (ou tracing garbage collection) e contagem de referências (reference counting) está na abordagem que cada técnica usa para identificar e liberar a memória de objetos que não estão mais em uso.
Vou explicar cada um e, em seguida, destacar as principais diferenças.

Contagem de Referências (Reference Counting)

Como funciona: Cada objeto na memória tem um contador que rastreia quantas referências (ou ponteiros) apontam para ele. Quando uma nova referência ao objeto é criada, o contador é incrementado. Quando uma referência é removida, o contador é decrementado. Se o contador atingir zero, significa que o objeto não é mais acessível e pode ser liberado (sua memória pode ser recolhida).
Vantagens:
- Simples de entender e implementar.
- Recolhe a memória imediatamente quando o contador chega a zero, o que pode reduzir a quantidade de memória usada.
Desvantagens:
- Ciclos de referência: Se dois ou mais objetos referenciam uns aos outros em um ciclo, suas contagens de referência nunca chegam a zero, causando vazamentos de memória.
- Pode ser menos eficiente, pois cada criação ou remoção de referência requer uma atualização do contador, o que pode ter um impacto no desempenho.

Rastreamento de Referências (Tracing Garbage Collection)

Como funciona: Esta abordagem envolve duas fases principais: marcação e varredura. Primeiro, o coletor de lixo (garbage collector) inicia a partir das raízes (como variáveis globais, locais e registradores) e rastreia todas as referências aos objetos na memória, marcando aqueles que são acessíveis. Em seguida, ele varre a memória para coletar (liberar) objetos que não foram marcados, pois esses não são mais acessíveis.
Vantagens:
- Não sofre de problemas de ciclos de referência, pois o coletor de lixo é capaz de identificar objetos que não são mais acessíveis, independentemente de ciclos.
- Pode ser mais eficiente em termos de tempo de execução para certos tipos de aplicações, especialmente em linguagens com gerenciamento de memória complexo.
Desvantagens:
- Pode introduzir pausas na execução do programa, embora os garbage collectors modernos, como o de Go, sejam projetados para minimizar essas pausas.
- Geralmente, o processo de rastreamento pode ser mais complexo e consome mais recursos do que a contagem de referências, dependendo de como o garbage collector é implementado.

Principais Diferenças

Gestão de Ciclos:
- Contagem de Referências: Problemas com ciclos de referência, onde dois ou mais objetos referenciam uns aos outros, resultando em vazamento de memória.
- Rastreamento: Não tem problemas com ciclos, pois o coletor rastreia e marca todos os objetos acessíveis.
Complexidade e Desempenho:
- Contagem de Referências: Simples, mas cada operação de incremento e decremento pode impactar o desempenho, especialmente em programas que fazem muitas operações com ponteiros.
- Rastreamento: Mais complexo e pode causar pausas na execução do programa, mas geralmente mais eficiente em lidar com diferentes padrões de uso de memória.
Tempo de Coleta:
- Contagem de Referências: Coleta a memória imediatamente quando a contagem chega a zero.
- Rastreamento: Coleta a memória periodicamente, quando o garbage collector executa seu ciclo.
Implementação:
- Contagem de Referências: Mais simples de implementar, mas menos robusto em aplicações complexas.
- Rastreamento: Mais robusto, mas a implementação do garbage collector pode ser bastante complexa.

Em resumo, a contagem de referências é mais simples e imediata, mas pode falhar em certos cenários (como ciclos de referência), enquanto o rastreamento é mais robusto e flexível, mas pode ter um impacto maior no desempenho devido à complexidade da sua implementação.

Tipos de estratégia de balanceamento de carga

Bruno Souza — Fri, 12 Jul 2024 15:41:30 +0000

Olá, Mentes Tech!

Trabalhei essa semana em um estratégia de balanceamento de cargas, e antes dessa pesquisa, confesso que conhecia/usava somente 3 das que estão na lista abaixo, bora falar de estratégias ?

O balanceamento de carga é uma técnica para melhorar a disponibilidade e a eficiência dos serviços de TI, distribuindo as cargas de trabalho de maneira equitativa entre vários recursos de computação.

Aqui estão algumas estratégias comuns de balanceamento de carga:

1. Round Robin

Descrição: As solicitações são distribuídas sequencialmente entre os servidores.
Vantagens: Simples de implementar e eficaz para cargas uniformemente distribuídas.
Desvantagens: Não leva em consideração a carga atual dos servidores, podendo sobrecarregar servidores mais lentos.

2. Least Connections

Descrição: As solicitações são enviadas para o servidor com o menor número de conexões ativas.
Vantagens: Ajuda a evitar sobrecarga em servidores ocupados.
Desvantagens: Pode não ser eficiente se as conexões tiverem durações variáveis.

3. Least Response Time

Descrição: Direciona as solicitações para o servidor com o menor tempo de resposta.
Vantagens: Geralmente resulta em uma distribuição mais equilibrada, considerando a capacidade de resposta dos servidores.
Desvantagens: Pode exigir monitoramento constante dos tempos de resposta.

4. IP Hash

Descrição: Usa um algoritmo de hash baseado no endereço IP do cliente para determinar o servidor de destino.
Vantagens: Garante que as solicitações de um cliente específico sejam sempre direcionadas ao mesmo servidor.
Desvantagens: Pode levar a uma distribuição desigual se os IPs não forem distribuídos uniformemente.

5. Weighted Round Robin

Descrição: Extensão do Round Robin, onde cada servidor é atribuído a um peso, e servidores com maior capacidade recebem mais solicitações.
Vantagens: Permite considerar as capacidades diferentes dos servidores.
Desvantagens: Requer configuração manual dos pesos, o que pode ser complexo.

6. Weighted Least Connections

Descrição: Combina os conceitos de Least Connections e pesos, direcionando as solicitações para servidores com menos conexões ativas, ponderados por sua capacidade.
Vantagens: Equilibra carga de forma mais eficaz em ambientes heterogêneos.
Desvantagens: Pode ser mais complexo de configurar e monitorar.

7. Random

Descrição: Direciona as solicitações para um servidor escolhido aleatoriamente.
Vantagens: Simples e pode ser eficaz em ambientes com servidores de capacidades semelhantes.
Desvantagens: Pode resultar em distribuição desigual e ineficiente.

8. Consistent Hashing

Descrição: Utiliza uma técnica de hash que mapeia solicitações para servidores de forma a minimizar a redistribuição de carga quando servidores são adicionados ou removidos.
Vantagens: Boa escalabilidade e estabilidade em sistemas dinâmicos.
Desvantagens: Pode ser complexo de implementar.

9. Server Health Monitoring

Descrição: Monitora a saúde dos servidores e desvia o tráfego de servidores que estão falhando ou sobrecarregados.
Vantagens: Aumenta a resiliência e a disponibilidade do sistema.
Desvantagens: Requer ferramentas adicionais e monitoramento contínuo.

10. Anycast Routing

Descrição: Usa a topologia da rede para direcionar as solicitações para o servidor mais próximo (em termos de roteamento).
Vantagens: Pode reduzir a latência.
Desvantagens: Pode ser complexo de implementar e depende da infraestrutura da rede.

Conclusão

Cada estratégia tem seus prós e contras, e a escolha da melhor técnica de balanceamento de carga depende das necessidades específicas da aplicação, da infraestrutura disponível e dos requisitos de desempenho e disponibilidade.

Após conhecer as estratégias disponíveis,
optei por usar o Weighted Round Robin, pois é o cenário proposto, dividir a carga de trabalho entre servidores.

O que é BDD e quando você deve considerar

Bruno Souza — Mon, 17 Jun 2024 23:06:10 +0000

Olá, Mentes Tech!

O desenvolvimento orientado por comportamento (Behavior-Driven Development, ou BDD) é uma abordagem de desenvolvimento de software que estende o Test-Driven Development (TDD) ao focar na colaboração entre desenvolvedores, testadores e stakeholders não técnicos.
O objetivo do BDD é garantir que todos os envolvidos no desenvolvimento do software compartilhem uma compreensão clara do comportamento desejado do sistema.

Repositório Github
Implementação realizada usando Golang e GoDog

Como Funciona o BDD

Especificação de comportamentos: No BDD, os requisitos do software são definidos como especificações de comportamento, geralmente utilizando a linguagem Gherkin.
Esta linguagem permite escrever cenários de teste em um formato de história, como "Dado, Quando, Então", que são compreensíveis tanto para técnicos quanto para não técnicos.
Cenários de teste: Esses cenários são descrições claras e detalhadas de como o sistema deve se comportar em determinadas situações. Por exemplo:

Feature: Calculator
  As a user
  I want to use a calculator
  So that I can add numbers

  Scenario: Add two numbers
    Given I have a calculator
    When I add 2 and 3
    Then the result should be 5

Automatização de testes: Esses cenários são então usados como base para criar testes automatizados.
Ferramentas como Cucumber, SpecFlow, ou Godog (para Go) executam esses cenários e verificam se o comportamento do sistema corresponde às especificações.
Desenvolvimento iterativo: O BDD promove um ciclo iterativo onde cenários de teste são escritos antes do desenvolvimento do código.
Isso garante que o desenvolvimento seja guiado pelos requisitos de comportamento do usuário.

Benefícios do BDD

Melhor comunicação e colaboração: O BDD facilita uma comunicação clara entre todos os membros da equipe.
As especificações de comportamento são escritas em uma linguagem natural, compreensível por todos, o que promove uma colaboração mais eficaz.
Requisitos claros e não ambíguos: A escrita de cenários de teste antes da codificação ajuda a esclarecer os requisitos, reduzindo ambiguidades e mal-entendidos.
Foco no valor de negócio: O BDD mantém o foco no comportamento que traz valor para o usuário final.
Isso ajuda a garantir que o software entregue realmente atenda às necessidades do negócio.
Documentação viva: Os cenários de BDD servem como uma documentação viva do sistema, sempre atualizada e refletindo o comportamento atual do software.
Testes automatizados: O BDD promove a criação de uma suite de testes automatizados robusta, facilitando a detecção precoce de erros e a realização de regressão.
Facilita a refatoração: Com uma suite de testes automatizados baseada em cenários de BDD, é mais fácil refatorar o código com confiança, sabendo que qualquer regressão será detectada imediatamente.
Maior confiança na qualidade: A combinação de especificações claras, colaboração eficaz e testes automatizados robustos resulta em maior confiança na qualidade do software entregue.

Por que você, como desenvolvedor, deve considerar usar BDD

Alinhamento com as expectativas do usuário: O BDD ajuda a garantir que você está desenvolvendo funcionalidades que realmente atendem às necessidades do usuário final, reduzindo retrabalho e ajustes tardios.
Redução de erros: Ao escrever testes antes do código, você pode detectar e corrigir problemas logo no início do processo de desenvolvimento, economizando tempo e esforço a longo prazo.
Documentação automática: Os cenários de teste servem como documentação do sistema, facilitando a manutenção e a compreensão do código, tanto para você quanto para novos membros da equipe.
Melhoria contínua: O BDD promove uma cultura de melhoria contínua, onde você está constantemente revisando e refinando tanto o código quanto os testes, resultando em um produto final de alta qualidade.
Confiança na refatoração: Com uma suite de testes robusta, você pode refatorar o código com segurança, sabendo que as mudanças serão verificadas automaticamente contra os cenários de comportamento especificados.

Em resumo, o BDD não só melhora a qualidade do software, mas também facilita a comunicação, colaboração e alinhamento entre todos os envolvidos no desenvolvimento, resultando em um processo de desenvolvimento mais eficiente e eficaz.

Kong Gateway - Validando configurações específicas para exposição de serviços

Bruno Souza — Fri, 31 May 2024 23:37:59 +0000

Olá, Mentes Tech!

Essa semana testei o deck files lint que é uma feature do deck, que usa o projeto vacuum para esta implementação.

[Caso Uso] Existe a necessidade de identificar o proprietário de cada rota em nosso ecossistema.
Como solução, foi requisitado que todas as rotas contenham a propriedade tags preenchida com nome da squad e que a versão do Kong seja mantida em 3.1.

Referência: Ruleset
Repositório: kong-business-rules-lint

Criei duas regras, uma para validar se a propriedade tag existe e possui valor, e a segunda regra é se a propriedade _format_version é 3.1.

Criei duas configurações de rotas

Então criei uma imagem com deck na versão latest

No Dockerfile tem comandos para validar o arquivo de configuração contra um ruleset.

RUN deck file validate corrupted.yml
RUN deck file lint -s corrupted.yml ruleset.yml

Chegamos ao fim...

como você configura seu Gateway Kong?

[Discussão] - Como você implementa suas apis ?

Bruno Souza — Tue, 21 May 2024 20:49:54 +0000

Olá, Mentes Tech!

Se você, como primeiro passo pensou em planejamento, temos algo em comum.

Planejar uma Api antes de meter a mão na massa, é a melhor decisão que você pode tomar antes de iniciar o desenvolvimento.

E no planejamento, a etapa de especificação não deve ser ignorada, esta etapa é crucial para garantir o sucesso da sua integração.

Por aqui, estou planejando minhas Apis, usando OAS 3.0
Editor Swagger - OAS 3.0

E aí, qual ferramenta você usa para planejar sua Api ?

Analogia receita de bolo VS algoritmo VS linguagem de programação

Bruno Souza — Tue, 21 May 2024 14:37:45 +0000

Olá, Mentes Tech!

Hoje me peguei pensando no que uma receita de bolo, algoritmos e linguagens de programação tem em comum.

Uma receita de bolo é um guia com passos bem definidos com um objetivo final de te entregar um bolo, desde que a receita seja seguida conforme descrito.

Na receita diz 2 ovos, mas eu só tenho 1, vai assim mesmo.
Pouts, deu errado, é culpa da receita.

O Algoritmo é uma sequencia lógica bem definida com instruções para máquina.

A linguagem de programação nesta analogia pode ser visto como os ingredientes para executar a receita que neste caso é o algoritmo.

Conclusão, se você possuir um bom raciocínio lógico para propor bons algoritmos, para resolver problemas complexos, a linguagem de programação será seu ingrediente premium para conclusão dos melhores "bolos".

E quanto mais linguagens conhecer, melhor será sua proposta para execução da "receita de bolo" e até mesmo aprimoramento da mesma.

Jornada pessoal em Machine Learning

Bruno Souza — Thu, 16 May 2024 15:57:54 +0000

Olá, Mentes Tech!

Quero muito contar como está sendo minha jornada estudando e construindo IA, matemática e estatística foi uma matéria que me cativou bastante durante a graduação, e a pouco tempo venho me aventurando com tensor flow + python para construção de modelos.

E está sendo incrível desenvolver, e com minha bagagem como dev facilitou alguns caminhos, principalmente na modelagem de dados, compreender profundamente estrutura de dados e algoritmo, tem me permitido deslanchar no desenvolvimento.

Está semana, eu conclui meu primeiro modelo, ele ainda está em treinamento, mas já é possível ver os resultados, como estou em fase de aprendizado (soa engraçado neh, aprendendo para ensinar), e contando um pouco mais é exatamente o tipo de ML que eu construí por aprendizado por reforço.

E o que ela faz?

Neste post aqui eu conto sobre a plataforma que estou construindo, e este modelo será para refinar as entradas e futuramente predizer o próximo fechamento.

Massa ou não ?

Por enquanto estou usando aprendizado por reforço, mas quero testar também, rede neural recorrente (RNN) com uma arquitetura de rede LSTM (Long Short-Term Memory).

E aí o que achou ?
Bora falar sobre ?

estou bastante empolgado.

DEV não coloque a mão na massa até ter certeza do que você deve implementar

Bruno Souza — Wed, 15 May 2024 14:05:29 +0000

Olá, Mentes Tech!

Se você disser sim, para qualquer das perguntas abaixo, este texto é para você.

Tenho retrabalho ?

A minha entrega não cumpre com o esperado pelo cliente ?

Não consigo entender o que o meu cliente quer ?

Na carreira de um Engenheiro de Software, isto é mais comum do que parece.

E pode acontecer quando o cliente está indeciso, quando não há clareza dos objetivos, quando não está relacionado a alguma métrica ou algum número que você gostaria que aumentasse ou diminuísse, uma ui que não está amigável.

Note que as situações o problema não está na sua implementação, mas na forma como você entendeu o desafio. concorda que aqui temos uma possibilidade do ponto de falha ser o planejamento, em vários níveis ?

Mas o meu foco é no desenvolvimento de software, imagine que você possui uma especificação do que o cliente quer.

Alinhe expectativas, faça protótipos, mapeie os pontos de solução em alto nível, um ponto de solução pode ser granular e pode chegar a nível de registradores, dependendo da entrega.

Antes de colocar a mão na massa.
Após alguns anos fazendo o planejamento antes da implementação, ir para IDE é somente para digitar, pois a solução já está validada planejada e vai fazer exatamente o que foi proposta para fazer no planejamento, note que todo esforço está concentrado no planejamento e não na execução.

Codificar virou apenas uma tarefa de digitação, ou delegar para o Copilot.

Como você planeja suas entregas ?

Por que você deveria priorizar a documentação de suas experiências

Bruno Souza — Fri, 26 Apr 2024 20:37:08 +0000

Olá, Mentes Tech!
Na anotação de hoje, gostaria de compartilhar por que você, tech leitor, deveria considerar escrever sobre suas experiências, seja de forma pública ou privada.

Após passar algum tempo como desenvolvedor de software, percebi que frequentemente me deparava com problemas que já havia resolvido em algum momento da minha carreira. Atualmente, os desafios que enfrento são complexo e meu time atua em componentes conceitualmente conhecidos como cross-cutting concerns.

Por isso, tornou-se essencial documentar minha jornada de alguma forma, seja para revisitar soluções aplicadas, reforçar o aprendizado, ou simplesmente documentar a experiência, que também pode servir para pessoas com menor senioridade.

Este post será um texto em constante evolução, uma fonte viva de motivação para que você também embarque nessa jornada de documentação.

Vamos começar a documentar!

Golang - Singleton Design pattern

Bruno Souza — Thu, 25 Apr 2024 23:42:36 +0000

Conceitualmente o padrão singleton define que somente uma instância deve existir em todo o sistema.
É como ter um guardião solitário que garante que apenas uma única cópia de si mesma esteja presente, independentemente de quantas vezes seja chamado.

Estou avançando nos estudos em golang e decidi mergulhar na implementação deste padrão tão debatido e controverso.
É aquele tipo de padrão que desperta paixões e críticas, amado por alguns como uma solução elegante e odiado por outros como um antipadrão a ser evitado a todo custo.

singleton.go

package main

import (
    "fmt"
    "sync"
)

var lock = &sync.Mutex{}

type singleton struct {
}

var singleInstance *singleton

func getInstance() *singleton {
    if singleInstance == nil {
        lock.Lock()
        defer lock.Unlock()
        if singleInstance == nil {
            fmt.Println("create singleton")
            singleInstance = &singleton{}
        } else {
            fmt.Println("singleton already created.")
        }
    } else {
        fmt.Println("singleton already created.")
    }

    return singleInstance
}

main.go

package main

import (
    "fmt"
)
func main() {
    for i := 0; i < 3; i++ {
        go getInstance()
    }
    fmt.Scanln()
}

Saída esperada

create singleton
singleton already created.
singleton already created.