O método Arrays.sort é bastante eficiente para a maioria dos casos, mas quando lidamos com arrays muito grandes, sua versão sequencial pode se tornar um gargalo, principalmente ao aproveitar apenas um único núcleo da CPU. Para arrays de tipos primitivos, o Java utiliza uma implementação de Dual-Pivot Quicksort, que tem, em média, complexidade de O(n log n). Entretanto, mesmo essa implementação bem otimizada pode enfrentar limitações em contextos de alto volume de dados, sobretudo se a ordenação for um dos pontos críticos de desempenho da aplicação.

Uma solução bastante interessante nesses cenários é utilizar o Arrays.parallelSort. Introduzido a partir do Java 8, esse método parte o array em segmentos menores e os classifica de forma concorrente, aproveitando o framework Fork/Join para distribuir as tarefas entre múltiplos núcleos. Essa abordagem pode reduzir significativamente o tempo total de ordenação em sistemas com múltiplos threads, especialmente em arrays de tamanho enorme. Além disso, para conjuntos de dados cuja chave seja numérica e limitada, algoritmos não-baseados em comparação, como Radix Sort ou Counting Sort, podem ser explorados, já que esses algoritmos podem apresentar desempenho linear sob determinadas condições.

Portanto, ao avaliar a performance do Arrays.sort com arrays grandes, a recomendação é considerar o uso de algoritmos paralelos, como o Arrays.parallelSort, que se aproveitam da arquitetura moderna multi-core. Essa solução não só melhora o tempo de execução, mas também distribui de forma mais equilibrada a carga de processamento, resultando em um desempenho superior para aplicações que lidam com volumes massivos de dados.

Você também pode explorar algoritmos específicos para tipos de dados particulares. Por exemplo, para ordenar strings ou outros objetos com um padrão de comparação complexo, uma combinação de particionamento eficiente e técnicas de otimização local pode trazer ganhos importantes. Essa abordagem pode ser ajustada conforme o perfil dos dados e o ambiente de execução, permitindo um balanceamento ideal entre uso de memória e velocidade de processamento.

O padrão de design de fábrica é usado quando temos uma superclasse com várias subclasses e, com base na entrada, precisamos retornar uma das subclasses. Esse padrão tira a responsabilidade da instanciação de uma classe do programa cliente para a classe de fábrica. Vamos primeiro aprender como implementar um padrão de design de fábrica em Java e, em seguida, veremos as vantagens do padrão de fábrica. Veremos alguns dos usos do padrão de design de fábrica no JDK. Observe que esse padrão também é conhecido como Padrão de Design de Método de Fábrica .

Padrão de Design de Fábrica Super Classe

A superclasse no padrão de design de fábrica pode ser uma interface, uma classe abstrata ou uma classe Java normal. Para nosso exemplo de padrão de design de fábrica, temos uma superclasse abstrata com um método sobrescrito toString() para fins de teste.

package com.journaldev.design.model;

public abstract class Computer {
	
	public abstract String getRAM();
	public abstract String getHDD();
	public abstract String getCPU();
	
	@Override
	public String toString(){
		return "RAM= "+this.getRAM()+", HDD="+this.getHDD()+", CPU="+this.getCPU();
	}
}

Subclasses de Padrão de Design de Fábrica

Digamos que temos duas subclasses, PC e Servidor, com a implementação abaixo.

package com.journaldev.design.model;

public class PC extends Computer {

	private String ram;
	private String hdd;
	private String cpu;
	
	public PC(String ram, String hdd, String cpu){
		this.ram=ram;
		this.hdd=hdd;
		this.cpu=cpu;
	}
	@Override
	public String getRAM() {
		return this.ram;
	}

	@Override
	public String getHDD() {
		return this.hdd;
	}

	@Override
	public String getCPU() {
		return this.cpu;
	}

}

Observe que ambas as classes estão estendendo Computera superclasse.

package com.journaldev.design.model;

public class Server extends Computer {

	private String ram;
	private String hdd;
	private String cpu;
	
	public Server(String ram, String hdd, String cpu){
		this.ram=ram;
		this.hdd=hdd;
		this.cpu=cpu;
	}
	@Override
	public String getRAM() {
		return this.ram;
	}

	@Override
	public String getHDD() {
		return this.hdd;
	}

	@Override
	public String getCPU() {
		return this.cpu;
	}

}

Classe de fábrica

Agora que temos superclasses e subclasses prontas, podemos escrever nossa classe de fábrica. Aqui está a implementação básica.

package com.journaldev.design.factory;

import com.journaldev.design.model.Computer;
import com.journaldev.design.model.PC;
import com.journaldev.design.model.Server;

public class ComputerFactory {

	public static Computer getComputer(String type, String ram, String hdd, String cpu){
		if("PC".equalsIgnoreCase(type)) return new PC(ram, hdd, cpu);
		else if("Server".equalsIgnoreCase(type)) return new Server(ram, hdd, cpu);
		
		return null;
	}
}

Alguns pontos importantes sobre o método Factory Design Pattern são:

1. Podemos manter a classe Factory Singleton ou podemos manter o método que retorna a subclasse como estático .
2. Observe que, com base no parâmetro de entrada, diferentes subclasses são criadas e retornadas. getComputeré o método de fábrica.

Aqui está um programa cliente de teste simples que usa a implementação do padrão de design de fábrica acima.

package com.journaldev.design.test;

import com.journaldev.design.factory.ComputerFactory;
import com.journaldev.design.model.Computer;

public class TestFactory {

	public static void main(String[] args) {
		Computer pc = ComputerFactory.getComputer("pc","2 GB","500 GB","2.4 GHz");
		Computer server = ComputerFactory.getComputer("server","16 GB","1 TB","2.9 GHz");
		System.out.println("Factory PC Config::"+pc);
		System.out.println("Factory Server Config::"+server);
	}

}

A saída do programa acima é:

Factory PC Config::RAM= 2 GB, HDD=500 GB, CPU=2.4 GHz
Factory Server Config::RAM= 16 GB, HDD=1 TB, CPU=2.9 GHz

Vantagens do Padrão de Projeto de Fábrica

1. O padrão de design de fábrica fornece uma abordagem ao código para interface em vez de implementação.
2. O padrão Factory remove a instanciação de classes de implementação reais do código do cliente. O padrão Factory torna nosso código mais robusto, menos acoplado e fácil de estender. Por exemplo, podemos facilmente alterar a implementação da classe PC porque o programa cliente não tem conhecimento disso.
3. O padrão de fábrica fornece abstração entre classes de implementação e cliente por meio de herança.

Exemplos de padrões de design de fábrica no JDK

1. Os métodos java.util.Calendar, ResourceBundle e NumberFormat getInstance()usam o padrão Factory.
2. valueOf()método em classes wrapper como Boolean, Integer etc.

Tutorial em vídeo do YouTube sobre o padrão de design de fábrica

Recentemente, carreguei um vídeo no YouTube para o padrão Factory Design, por favor, dê uma olhada. Por favor, curta e compartilhe o vídeo e inscreva-se no meu canal do YouTube. https://www.youtube.com/watch?v=J1QU\_R4MQQc

Você pode baixar o código de exemplo do meu Projeto GitHub .

Implementação do Padrão Java Singleton

Para implementar um padrão singleton, temos diferentes abordagens, mas todas elas têm os seguintes conceitos comuns.

• Construtor privado para restringir a instanciação da classe de outras classes.
• Variável estática privada da mesma classe que é a única instância da classe.
• Método estático público que retorna a instância da classe. Este é o ponto de acesso global para o mundo externo obter a instância da classe singleton.

Nas próximas seções, aprenderemos diferentes abordagens para implementação de padrões singleton e preocupações de design com a implementação.

1. Inicialização rápida

Na inicialização ansiosa, a instância da classe singleton é criada no momento do carregamento da classe. A desvantagem da inicialização ansiosa é que o método é criado mesmo que o aplicativo cliente não o esteja usando. Aqui está a implementação da classe singleton de inicialização estática:

package com.journaldev.singleton;

public class EagerInitializedSingleton {

    private static final EagerInitializedSingleton instance = new EagerInitializedSingleton();

    // private constructor to avoid client applications using the constructor
    private EagerInitializedSingleton(){}

    public static EagerInitializedSingleton getInstance() {
        return instance;
    }
}

Se sua classe singleton não estiver usando muitos recursos, essa é a abordagem a ser usada. Mas na maioria dos cenários, classes singleton são criadas para recursos como Sistema de Arquivos, conexões de Banco de Dados, etc. Devemos evitar a instanciação, a menos que o cliente chame o getInstancemétodo. Além disso, esse método não fornece nenhuma opção para tratamento de exceções.

2. Inicialização de bloco estático

A implementação da inicialização de bloco estático é semelhante à inicialização ansiosa, exceto que a instância da classe é criada no bloco estático que fornece a opção de tratamento de exceções .

package com.journaldev.singleton;

public class StaticBlockSingleton {

    private static StaticBlockSingleton instance;

    private StaticBlockSingleton(){}

    // static block initialization for exception handling
    static {
        try {
            instance = new StaticBlockSingleton();
        } catch (Exception e) {
            throw new RuntimeException("Exception occurred in creating singleton instance");
        }
    }

    public static StaticBlockSingleton getInstance() {
        return instance;
    }
}

Tanto a inicialização rápida quanto a inicialização de bloco estático criam a instância antes mesmo que ela seja usada, e essa não é a melhor prática a ser usada.

3. Inicialização preguiçosa

O método de inicialização lazy para implementar o padrão singleton cria a instância no método de acesso global. Aqui está o código de exemplo para criar a classe singleton com esta abordagem:

package com.journaldev.singleton;

public class LazyInitializedSingleton {

    private static LazyInitializedSingleton instance;

    private LazyInitializedSingleton(){}

    public static LazyInitializedSingleton getInstance() {
        if (instance == null) {
            instance = new LazyInitializedSingleton();
        }
        return instance;
    }
}

A implementação anterior funciona bem no caso do ambiente single-threaded, mas quando se trata de sistemas multi-threaded, pode causar problemas se vários threads estiverem dentro da ifcondição ao mesmo tempo. Isso destruirá o padrão singleton e ambos os threads obterão instâncias diferentes da classe singleton. Na próxima seção, veremos diferentes maneiras de criar uma classe singleton thread-safe .

4. Singleton seguro para threads

Uma maneira simples de criar uma classe singleton thread-safe é fazer com que o método de acesso global seja sincronizado para que apenas uma thread possa executar esse método por vez. Aqui está uma implementação geral dessa abordagem:

package com.journaldev.singleton;

public class ThreadSafeSingleton {

    private static ThreadSafeSingleton instance;

    private ThreadSafeSingleton(){}

    public static synchronized ThreadSafeSingleton getInstance() {
        if (instance == null) {
            instance = new ThreadSafeSingleton();
        }
        return instance;
    }

}

A implementação anterior funciona bem e fornece segurança de thread, mas reduz o desempenho devido ao custo associado ao método synchronized, embora precisemos dele apenas para os primeiros threads que podem criar instâncias separadas. Para evitar essa sobrecarga extra toda vez, o princípio de bloqueio verificado duas vezes é usado. Nessa abordagem, o bloco synchronized é usado dentro da ifcondição com uma verificação adicional para garantir que apenas uma instância de uma classe singleton seja criada. O seguinte trecho de código fornece a implementação de bloqueio verificado duas vezes:

public static ThreadSafeSingleton getInstanceUsingDoubleLocking() {
    if (instance == null) {
        synchronized (ThreadSafeSingleton.class) {
            if (instance == null) {
                instance = new ThreadSafeSingleton();
            }
        }
    }
    return instance;
}

Continue seu aprendizado com a classe Thread Safe Singleton .

5. Implementação de Bill Pugh Singleton

Antes do Java 5, o modelo de memória Java tinha muitos problemas, e as abordagens anteriores costumavam falhar em certos cenários em que muitos threads tentavam obter a instância da classe singleton simultaneamente. Então Bill Pugh surgiu com uma abordagem diferente para criar a classe singleton usando uma classe auxiliar estática interna . Aqui está um exemplo da implementação do Singleton de Bill Pugh:

package com.journaldev.singleton;

public class BillPughSingleton {

    private BillPughSingleton(){}

    private static class SingletonHelper {
        private static final BillPughSingleton INSTANCE = new BillPughSingleton();
    }

    public static BillPughSingleton getInstance() {
        return SingletonHelper.INSTANCE;
    }
}

Observe a classe estática interna privada que contém a instância da classe singleton. Quando a classe singleton é carregada, SingletonHelpera classe não é carregada na memória e somente quando alguém chama o getInstance()método, essa classe é carregada e cria a instância da classe singleton. Essa é a abordagem mais amplamente usada para a classe singleton, pois não requer sincronização.

6. Usando Reflexão para destruir o Padrão Singleton

A reflexão pode ser usada para destruir todas as abordagens de implementação singleton anteriores. Aqui está uma classe de exemplo:

package com.journaldev.singleton;

import java.lang.reflect.Constructor;

public class ReflectionSingletonTest {

    public static void main(String[] args) {
        EagerInitializedSingleton instanceOne = EagerInitializedSingleton.getInstance();
        EagerInitializedSingleton instanceTwo = null;
        try {
            Constructor[] constructors = EagerInitializedSingleton.class.getDeclaredConstructors();
            for (Constructor constructor : constructors) {
                // This code will destroy the singleton pattern
                constructor.setAccessible(true);
                instanceTwo = (EagerInitializedSingleton) constructor.newInstance();
                break;
            }
        } catch (Exception e) {
            e.printStackTrace();
        }
        System.out.println(instanceOne.hashCode());
        System.out.println(instanceTwo.hashCode());
    }

}

Ao executar a classe de teste anterior, você notará que hashCodeambas as instâncias não são as mesmas, o que destrói o padrão singleton. O Reflection é muito poderoso e usado em muitos frameworks como Spring e Hibernate. Continue seu aprendizado com o Tutorial Java Reflection .

7. Enumeração Singleton

Para superar essa situação com o Reflection, Joshua Bloch sugere o uso de enumpara implementar o padrão de design singleton, já que Java garante que qualquer enumvalor seja instanciado apenas uma vez em um programa Java. Como os valores Java Enum são globalmente acessíveis, o singleton também é. A desvantagem é que o enumtipo é um tanto inflexível (por exemplo, ele não permite inicialização preguiçosa).

package com.journaldev.singleton;

public enum EnumSingleton {

    INSTANCE;

    public static void doSomething() {
        // do something
    }
}

8. Serialização e Singleton

Às vezes, em sistemas distribuídos, precisamos implementar Serializableinterface na classe singleton para que possamos armazenar seu estado no sistema de arquivos e recuperá-lo em um momento posterior. Aqui está uma pequena classe singleton que implementa Serializableinterface também:

package com.journaldev.singleton;

import java.io.Serializable;

public class SerializedSingleton implements Serializable {

    private static final long serialVersionUID = -7604766932017737115L;

    private SerializedSingleton(){}

    private static class SingletonHelper {
        private static final SerializedSingleton instance = new SerializedSingleton();
    }

    public static SerializedSingleton getInstance() {
        return SingletonHelper.instance;
    }

}

O problema com a classe singleton serializada é que sempre que a desserializamos, ela criará uma nova instância da classe. Aqui está um exemplo:

package com.journaldev.singleton;

import java.io.FileInputStream;
import java.io.FileNotFoundException;
import java.io.FileOutputStream;
import java.io.IOException;
import java.io.ObjectInput;
import java.io.ObjectInputStream;
import java.io.ObjectOutput;
import java.io.ObjectOutputStream;

public class SingletonSerializedTest {

    public static void main(String[] args) throws FileNotFoundException, IOException, ClassNotFoundException {
        SerializedSingleton instanceOne = SerializedSingleton.getInstance();
        ObjectOutput out = new ObjectOutputStream(new FileOutputStream(
                "filename.ser"));
        out.writeObject(instanceOne);
        out.close();

        // deserialize from file to object
        ObjectInput in = new ObjectInputStream(new FileInputStream(
                "filename.ser"));
        SerializedSingleton instanceTwo = (SerializedSingleton) in.readObject();
        in.close();

        System.out.println("instanceOne hashCode="+instanceOne.hashCode());
        System.out.println("instanceTwo hashCode="+instanceTwo.hashCode());

    }

}

Esse código produz esta saída:

instanceOne hashCode=2011117821
instanceTwo hashCode=109647522

Então ele destrói o padrão singleton. Para superar esse cenário, tudo o que precisamos fazer é fornecer a implementação do readResolve()método.

protected Object readResolve() {
    return getInstance();
}

Depois disso, você notará que hashCodeambas as instâncias são iguais no programa de teste.

Fonte: https://www.digitalocean.com/community/tutorials/java-singleton-design-pattern-best-practices-examples