Capítulo 1: Erros Comuns no Uso do Singleton com DontDestroyOnLoad

No desenvolvimento com Unity, o padrão Singleton é frequentemente utilizado para garantir que uma instância de classe seja globalmente única, enquanto DontDestroyOnLoad é amplamente usado para manter objetos entre cenas. No entanto, desenvolvedores frequentemente combinam os dois de forma simplista, considerando-os uma "solução universal", ignorando defeitos de design potenciais e exceções em tempo de execução.

Cenários de Uso Incorreto

• Chamar DontDestroyOnLoad sem verificar se a instância já existe, resultando em múltiplas instâncias coexistindo.
• Recriar o singleton após a troca de cena, violando a restrição de unicidade.
• Ignorar o gerenciamento do ciclo de vida, causando vazamentos de memória ou exceções de referência nula.

Implementação Correta

Abaixo está uma implementação de classe base Singleton thread-safe que evita carregamento duplicado:

// Classe base Singleton para Unity, auto-montada e evita destruição
public class SingletonBase<T> : MonoBehaviour where T : MonoBehaviour
{
    private static T _cachedInstance;
    private static readonly object _syncLock = new object();

    public static T CurrentInstance
    {
        get
        {
            if (_cachedInstance == null)
            {
                // Bloqueio de verificação dupla
                lock (_syncLock)
                {
                    if (_cachedInstance == null)
                    {
                        var targetObject = new GameObject(typeof(T).Name);
                        _cachedInstance = targetObject.AddComponent<T>();
                        DontDestroyOnLoad(targetObject); // Chamado apenas aqui
                    }
                }
            }
            return _cachedInstance;
        }
    }

    protected virtual void Awake()
    {
        // Impede a adição manual externa de múltiplas instâncias
        if (_cachedInstance != null && _cachedInstance != this)
        {
            Destroy(gameObject);
        }
        else
        {
            _cachedInstance = this as T;
        }
    }
}

Tabela Comparativa de Comportamento Chave

Método de Uso	Garante Unicidade	Sobrevive Entre Cenas	Nível de Risco
Apenas Padrão Singleton	Sim	Não	Baixo
Apenas DontDestroyOnLoad	Não	Sim	Alto
Combinação Correta	Sim	Sim	Baixo

Fluxo de Decisão para Obtenção da Instância

graph TD
    A[Tentar obter Instance] --> B{Instance já existe?}
    B -- Sim --> C[Retornar instância existente]
    B -- Não --> D[Criar novo GameObject]
    D --> E[Adicionar componente T]
    E --> F[Chamar DontDestroyOnLoad]
    F --> G[Retornar nova instância]

Capítulo 2: Princípios do Singleton em Unity

2.1 Conceito Central e Intenção de Design do Singleton

O padrão Singleton é um padrão de criação que garante que uma classe tenha apenas uma instância e fornece um ponto de acesso global. Seu núcleo está em controlar o processo de criação do objeto, evitando instanciações repetidas, comumente usado em gerenciamento de configuração, serviços de log, etc.

Implementação e Segurança de Threads

Em ambientes multithread, é necessário garantir a unicidade do singleton. Em Go, isso pode ser alcançado com sync.Once para carregamento preguiçoso:

var singletonOnce sync.Once
var logInstance *Logger

func GetLogger() *Logger {
    singletonOnce.Do(func() {
        logInstance = &Logger{}
    })
    return logInstance
}

O código acima usa sync.Once para garantir que a lógica de inicialização seja executada apenas uma vez. O parâmetro singletonOnce é uma primitiva de sincronização que previne condições de corrida; GetLogger é o método de acesso global que cria a instância sob demanda, otimizando o uso de recursos.

Análise de Cenários de Aplicação

• Gerenciamento de pool de conexões de banco de dados
• Compartilhamento de manipuladores de sistema de arquivos
• Ponto de entrada unificado para serviços de cache

2.2 Implementação Típica de Singleton em C# para Unity

No desenvolvimento com Unity, o padrão Singleton é amplamente usado para gerenciar serviços ou sistemas globais, como gerenciamento de áudio, controle de estado do jogo. A combinação de atributos estáticos e construtores privados garante que a classe tenha apenas uma instância.

Singleton Básico (Não Thread-Safe)

public class GameController : MonoBehaviour
{
    private static GameController _singletonRef;
    public static GameController Singleton
    {
        get
        {
            if (_singletonRef == null)
                _singletonRef = FindObjectOfType<GameController>();
            return _singletonRef;
        }
    }

    private void Awake()
    {
        if (_singletonRef == null)
            _singletonRef = this;
        else if (_singletonRef != this)
            Destroy(gameObject);
    }
}

Esta implementação usa FindObjectOfType para localizar a instância na cena e previne a criação duplicada no Awake, sendo adequada para cenários simples.

Singleton Persistente Otimizado

Para evitar a perda durante trocas de cena, pode-se chamar DontDestroyOnLoad(transform.root.gameObject); na inicialização do singleton, garantindo que o objeto persista entre cenas.

2.3 Relação entre Campos Estáticos e Gerenciamento de Ciclo de Vida

Campos estáticos são inicializados quando a classe é carregada, e seu ciclo de vida dura todo o período de execução da aplicação, não sendo afetado pela criação e destruição de instâncias. Isso os torna comumente usados para armazenar configurações globais ou recursos compartilhados.

Risco de Vazamento de Memória

Se um campo estático mantiver referências a objetos, pode impedir que esses objetos sejam coletados pelo lixo, causando vazamento de memória. Exemplo:

public class DataCache {
    private static List<object> _storage = new List<object>();
    
    public static void Store(object item) {
        _storage.Add(item); // Mantém referência por tempo indeterminado
    }
}

No código acima, _storage como campo estático mantém referências contínuas aos objetos, mesmo quando não são mais usados externamente, impedindo a coleta.

Conflito com o Ciclo de Vida de Componentes

Em frameworks como Android ou Spring, campos estáticos podem ultrapassar o ciclo de vida de Activities ou Beans, levando a estados inconsistentes. Recomenda-se combinar com referências fracas (WeakReference) ou mecanismos de limpeza manual.

• Ciclo de vida do campo estático > ciclo de vida da instância
• Uso inadequado facilmente leva ao acúmulo de recursos
• Deve-se evitar manter referências a classes internas não estáticas por muito tempo

2.4 Mecanismo de Sobrevivência do Singleton em Trocas de Cenas

Em arquiteturas de aplicação complexas, objetos singleton precisam manter consistência de estado entre diferentes cenários de execução (como primeiro/segundo plano, múltiplas sessões de usuário). O ambiente JVM ou de runtime normalmente garante a unicidade do singleton através do mecanismo de carregador de classes, mas em cenários cross-processo ou reinicializações a quente, seu estado de sobrevivência pode ser comprometido.

Estratégias de Gerenciamento de Ciclo de Vida

• Usar contêineres para gerenciar o ciclo de vida do singleton, evitando liberação manual
• Registrar ouvintes durante trocas de cena, atrasando a destruição de instâncias críticas
• Associar contexto através de referências fracas, prevenindo vazamentos de memória

Exemplo de Código: Singleton com Sensibilidade ao Contexto

public class ContextAwareSingleton {
    private static volatile ContextAwareSingleton _instance;
    private object _currentContext;

    public static ContextAwareSingleton GetInstance() {
        if (_instance == null) {
            synchronized (typeof(ContextAwareSingleton)) {
                if (_instance == null) {
                    _instance = new ContextAwareSingleton();
                }
            }
        }
        return _instance;
    }

    public void UpdateContext(object ctx) {
        this._currentContext = ctx; // Atualiza contexto na troca de cena
    }
}

A implementação acima usa bloqueio de verificação dupla para garantir segurança de threads, e o método UpdateContext permite que o singleton perceba e se adapte ao cenário de execução atual, mantendo a continuidade da funcionalidade.

2.5 Princípio de Funcionamento e Momento de Chamada do DontDestroyOnLoad

No Unity, o método DontDestroyOnLoad é usado para tornar um GameObject não destruído durante trocas de cena, comumente usado para gerenciar objetos gerenciadores globais entre cenas.

Princípio de Funcionamento

Quando DontDestroyOnLoad(gameObject) é chamado, o objeto é removido da hierarquia da cena atual e acoplado a uma cena especial chamada "DontDestroyOnLoad". A partir de então, mesmo com o carregamento de novas cenas, o objeto permanece na memória.

using UnityEngine;

public class ServiceManager : MonoBehaviour
{
    private static ServiceManager _instance;

    void Awake()
    {
        if (_instance == null)
        {
            _instance = this;
            DontDestroyOnLoad(gameObject); // Impede a destruição
        }
        else
        {
            Destroy(gameObject); // Evita instâncias duplicadas
        }
    }
}

O código acima garante que o singleton ServiceManager persista durante trocas de cena. Se já existir uma instância, a nova é destruída, prevenindo duplicatas.

Momento de Chamada

O melhor momento para a chamada é durante Awake() ou Start(). Chamadas muito cedo ou muito tarde podem levar à destruição incorreta do objeto ou a exceções de referência nula.

Capítulo 3: Riscos de Memória Inerentes ao DontDestroyOnLoad

3.1 Mecanismo de Manutenção de Referência por Trás de Objetos Residentes

No sistema de runtime da linguagem Go, se um objeto pode permanecer na memória a longo prazo, o ponto crucial depende de seu estado de referência. Desde que exista pelo menos um potneiro ativo referenciando o objeto, o coletor de lixo (GC) não o coletará.

Referência Forte Mantém o Ciclo de Vida do Objeto

Quando um objeto é referenciado por uma variável global, variável local na pilha ou outro objeto no heap, ele é marcado como "alcançável" e, portanto, retido na memória.

var globalRef *MyDataStructure

func MaintainReference() {
    dataObj := &MyDataStructure{Name: "persistent"}
    globalRef = dataObj // A referência global mantém o objeto residente
}

No código acima, globalRef como variável global mantém uma referência forte a dataObj, impedindo sua coleta pelo GC.

Comparação de Tipos de Relação de Referência

Tipo de Referência	Impede o GC	Cenário Típico
Referência Forte	Sim	Atribuição comum de ponteiro
Referência Fraca	Não	Ao usar finalizadores

3.2 Casos de Vazamento Causados por Subscrição de Eventos e Referências Estáticas

Incompatibilidade de Ciclo de Vida em Subscrições de Eventos

Em linguagens com mecanismos de eventos como .NET ou JavaScript, se um objeto subscreve a um evento estático mas não cancela a subscrição ao ser destruído, isso fará com que o objeto não possa ser coletado como lixo. Eventos estáticos mantêm referências fortes aos assinantes, forçando a extensão do ciclo de vida do objeto assinante.

• Comum em barramentos de eventos, mecanismos de notificação global
• O assinante já está inválido, mas ainda é referenciado por um membro estático
• Causa crescimento contínuo da memória, eventualmente levando a vazamento

Exemplo de Código Típico

public static class DataEventBus
{
    public static event Action OnDataReady;

    public static void FireEvent() => OnDataReady?.Invoke();
}

public class DataConsumer
{
    public DataConsumer()
    {
        DataEventBus.OnDataReady += ProcessData; // Subscreve ao evento estático
    }

    private void ProcessData() { /* Lógica de processamento */ }
}

No código acima, após a instância de DataConsumer se registrar no evento estático, mesmo que não seja mais usada, não pode ser liberada, pois DataEventBus ainda mantém referência ao seu método.

Sugestões de Solução

Implementar mecanismos de cancelamento explícito ou usar o padrão de evento fraco (Weak Event Pattern) para evitar dependências de referência forte.

3.3 Problemas de Crescimento de Memória Causados por Não Liberação de Referências a Recursos

Em aplicações em execução por longo tempo, referências a recursos não liberadas corretamente são uma causa comum de crescimento contínuo de memória. Mesmo que a linguagem possua coletor de lixo, objetos podem permanecer inacessíveis devido a serem mantidos acidentalmente.

Cenário Típico: Vazamento de Descritores de Arquivo e Conexões de Banco de Dados

Desenvolvedores frequentemente ignoram operações de fechamento de fluxos de arquivo ou conexões de banco de dados, levando ao acúmulo de ocupação de recursos do sistema.

file, err := os.Open("large.log")
if err != nil {
    log.Fatal(err)
}
// Esqueceu de chamar defer file.Close()
data, _ := io.ReadAll(file)

No código acima, falta defer file.Close(), resultando em descritores de arquivo não liberados; múltiplas chamadas podem esgotar os descritores do sistema.

Estratégias de Diagnóstico e Prevenção

• Usar pprof para analisar snapshots de memória, localizando caminhos de referência persistente
• Garantir que todo recurso adquirido tenha sua lógica de liberação registrada imediatamente via defer
• Configurar um número máximo de conexões ociosas e mecanismos de expiração em pools de conexões

Capítulo 4: Estratégias Práticas para Uso Seguro do Singleton + DontDestroyOnLoad

4.1 Design Correto de Lógica de Destruição e Limpeza do Singleton

Em arquiteturas de aplicação modernas, embora o padrão Singleton garanta a unicidade do objeto, a falta de mecanismos razoáveis de destruição e limpeza de recursos pode facilmente causar vazamentos de memória ou problemas de ocupação de recursos.

Liberação de Recursos no Destruidor

A lógica de liberação de recursos críticos (como descritores de arquivo, conexões de rede) deve ser colocada no destruidor, garantindo que seja acionada automaticamente ao destruir a instância.

func (s *ResourceManager) Release() {
    if s.databaseConn != nil {
        s.databaseConn.Close()  // Fecha a conexão com o banco de dados
        s.databaseConn = nil
    }
    if s.fileHandle != nil {
        s.fileHandle.Close() // Libera o descritor de arquivo
        s.fileHandle = nil
    }
}

O método acima libera explicitamente os recursos mantidos e define os ponteiros como nil, prevenindo acesso a ponteiros inválidos.

Registro de Ganchos de Destruição

Podemos registrar callbacks de limpeza via pacotes de runtime, garantindo que a lógica de destruição seja chamada antes da saída do programa:

• Usar runtime.SetFinalizer para configurar finalizadores
• Ou chamar Release() ativamente na escuta de sinais

4.2 Uso de Referências Fracas ou Sistemas de Mensagens para Desacoplar Dependências

Em sistemas complexas, dependências fortes entre objetos podem facilmente causar vazamentos de memória e dificuldades de manutenção. O uso de referências fracas evita a manutenção de referências fortes a objetos, permitindo que o mecanismo de coleta de lixo funcione normalmente.

Exemplo de Referência Fraca (Java)

WeakReference<DataProcessor> weakRef = 
    new WeakReference<>(new DataProcessor());
// Quando não houver referência forte, DataProcessor pode ser coletado pelo GC
if (weakRef.get() != null) {
    weakRef.get().Process();
}

O código acima envolve o objeto alvo com WeakReference, evitando a vinculação do ciclo de vida. É adequado para cenários como cache e ouvintes.

Desacoplamento via Sistema de Mensagens

Usar um barramento de eventos ou padrão publicar-subscriber, onde componentes se comunicam através de mensagens sem referências diretas.

• O publicador envia eventos, sem se importar com os receptores
• O assinante escuta tipos de mensagem específicos
• O acoplamento geral do sistema é significativamente reduzido

4.3 Detecção e Monitoramento de Recursos Durante Trocas de Cena

Em arquiteturas multicena, a troca de cena geralmente é acompanhada por mudanças no estado dos recursos, sendo necessária detecção e monitoramento em tempo real para garantir a estabilidade do sistema.

Mecanismo de Verificação de Saúde dos Recursos

Usar sondas periódicas para detectar a disponibilidade de recursos críticos, como conexões de banco de dados, serviços de cache. Abaixo um exemplo de verificação de saúde baseado em Go:

func CheckServiceHealth(ctx context.Context, endpoint string) error {
    request, _ := http.NewRequestWithContext(ctx, "GET", endpoint+"/health", nil)
    response, err := http.DefaultClient.Do(request)
    if err != nil {
        return fmt.Errorf("recurso inacessível: %w", err)
    }
    defer response.Body.Close()
    if response.StatusCode != http.StatusOK {
        return fmt.Errorf("falha na verificação de saúde com status: %d", response.StatusCode)
    }
    return nil
}

Esta função controla timeout através de contexto, evitando bloqueio do processo de troca; retorna informações de erro para localizar a fonte da falha.

Coleta de Métricas de Monitoramento

Usar formato Prometheus para expor métricas em tempo de execução, com dados-chave incluindo uso de memória, número de conexões, latência de resposta.

Nome da Métrica	Tipo	Finalidade
scene_switch_duration_ms	Gauge	Medir tempo de troca
active_resources_count	Counter	Contar instâncias de recursos ativas

4.4 Melhores Práticas para Singletons de Classe de Utilidade

Ao construir sistemas de alta concorrência, a segurança de threads e reutilização de recursos de classes de utilidade são cruciais. O uso do padrão Singleton pode efetivamente evitar custos de inicialização repetida.

Inicialização Preguiçosa e Segurança de Threads

Implementar singleton preguiçoso em linguagem Go e garantir desempenho e segurança através de bloqueio de verificação dupla:

var (
    configInstance *ConfigurationManager
    configOnce     sync.Once
)

type ConfigurationManager struct {
    settings map[string]string
}

func GetConfigurationManager() *ConfigurationManager {
    if configInstance == nil {
        configOnce.Do(func() {
            configInstance = &ConfigurationManager{
                settings: make(map[string]string),
            }
        })
    }
    return configInstance
}

Esta implementação usa sync.Once para garantir que a inicialização seja executada apenas uma vez, evitando a perda de desempenho de bloqueios explícitos, enquanto previne vazamentos de memória e condições de corrida.

Comparação de Cenários de Aplicação

• Registrador de logs: canal de saída global único, facilitando o gerenciamento centralizado
• Pool de conexões de banco de dados: reduz custo de criação de conexões, melhora velocidade de resposta
• Carregador de configurações: ponto de acesso unificado para configurações, suporta mecanismo de atualização a quente