ExecutorService vs ThreadPoolExecutor à l'aide de LinkedBlockingQueue

Je suis en train de travailler sur un multithread projet dans lequel j'ai besoin de générer plusieurs threads à mesure de la fin à la fin de l'exécution de mon code client, car je fais de la Charge et des tests de Performances. J'ai donc créé le code ci-dessous qui est à l'aide de ExecutorService.

Ci-dessous est le code avec ExecutorService:

public class MultithreadingExample {

    public static void main(String[] args) throws InterruptedException {

        ExecutorService executor = Executors.newFixedThreadPool(20);
        for (int i = 0; i < 100; i++) {
            executor.submit(new NewTask());
        }

        executor.shutdown();
        executor.awaitTermination(Long.MAX_VALUE, TimeUnit.DAYS);
    }
}

class NewTask implements Runnable {

    @Override
    public void run() {
        //Measure the end to end latency of my client code
    }   
}

Énoncé du problème:

Maintenant, j'ai lu quelques article sur Internet. J'ai découvert il y a ThreadPoolExecutor ainsi. Donc, je n'ai pas compris qui je doit utiliser.

Si je remplace mon code ci-dessus à partir de:

ExecutorService executor = Executors.newFixedThreadPool(20);
    for (int i = 0; i < 100; i++) {
        executor.submit(new NewTask());
    }

à:

BlockingQueue<Runnable> threadPool = new LinkedBlockingQueue<Runnable>();

ThreadPoolExecutor tpExecutor = new ThreadPoolExecutor(20, 2000, 0L, TimeUnit.MILLISECONDS, threadPool);

tpExecutor.prestartAllCoreThreads();

    for (int i = 0; i < 100; i++) {
        tpExecutor.execute(new NewTask());
    }

cela fera toute la différence? Je suis en train d'essayer de comprendre quelle est la différence entre mon code d'origine à l'aide de ExecutorService et le nouveau code collé à l'aide de ThreadPoolExecutor. Certains de mes coéquipiers, a déclaré seconde (ThreadPoolExecutor) est la bonne façon de l'utiliser.

Quelqu'un peut-il préciser ce pour moi?

InformationsquelleAutor | 2013-04-23
  1. 73

    Ici est la source de Executors.newFixedThreadPool:

     public static ExecutorService newFixedThreadPool(int nThreads) {
    return new ThreadPoolExecutor(nThreads, nThreads,
                                  0L, TimeUnit.MILLISECONDS,
                                  new LinkedBlockingQueue<Runnable>());
}

    Il utilise en interne ThreadPoolExecutor classe avec la configuration par défaut comme vous pouvez le voir ci-dessus. Maintenant, il existe des scénarios où la configuration par défaut ne convient pas dire à la place de LinkedBlockingQueue une file d'attente de priorité doit être utilisé, etc. Dans de tels cas, l'appelant peut travailler directement sur les sous-jacents ThreadPoolExecutor par instanciation et en passant de la configuration souhaitée pour elle.

    InformationsquelleAutor harsh
  2. 23

    alors qui va faire une différence?

    Il permet de rendre votre code plus compliqué pour peu d'avantages.

    J'essaie de comprendre quelle est la différence entre mon code d'origine qui est à l'aide de ExecutorService et le nouveau code, que j'ai collé qui est à l'aide de ThreadPoolExectuor?

    À côté de rien. Executors crée un ThreadPoolExecutor pour faire le vrai travail.

    Certains de mes coéquipiers, a déclaré seconde (ThreadPoolExecutor) est la bonne façon de l'utiliser?

    Juste parce que c'est plus compliqué ne veut pas dire que c'est la bonne chose à faire. Les concepteurs ont fourni les Exécuteurs testamentaires.newXxxx méthodes pour rendre la vie plus simple pour vous et parce qu'ils s'attendaient à l'utilisation de ces méthodes. Je vous suggère de les utiliser ainsi.

    • Vous avez parlé un peu de profit? Qu'est-ce que tout cela? Et derrière la scène Exécuteurs appelé ThreadPoolExecutor droit? Mais je crois qu'il utilise la Surabondance de la file d'attente qui est un peu lent, je suppose? Corrigez-moi si je me trompe.
    • Le peu d'avantages est que vous pouvez jouer avec les arguments du constructeur, mais ce n'est généralement pas une bonne idée. Vous avez fourni la même surabondance de la file d'attente, donc je ne vois pas votre point de vue. Si elle est lente, pourquoi les concepteurs de l'utiliser?
    • Il y a un coût à l'aide de LinkedBoundedQueue. Il n'a rien à voir avec le fait qu'elle est illimitée, et il est très faible par rapport au coût de passant à des tâches entre les threads, qui, je suppose que vous n'êtes pas trop inquiet à ce sujet.
    • Pour moi il y a une grande différence, parce que j'ai besoin d'ajuster le nombre de threads de manière dynamique.
    InformationsquelleAutor Peter Lawrey
  3. 13

    1. Les exécuteurs#newFixedThreadPool(int nThreads)

      ExecutorService executor = Executors.newFixedThreadPool(20);

    est fondamentalement 

     return new ThreadPoolExecutor(20, 20,
                                  0L, TimeUnit.MILLISECONDS,
                                  new LinkedBlockingQueue<Runnable>());

    2.

    BlockingQueue<Runnable> threadPool = new LinkedBlockingQueue<Runnable>();
ThreadPoolExecutor tpExecutor = new ThreadPoolExecutor(20, 2000, 0L,
    TimeUnit.MILLISECONDS, threadPool);

    Dans le second cas, vous êtes juste d'augmenter la maxPoolSize à 2000, ce dont je doute que vous auriez besoin.

    InformationsquelleAutor NINCOMPOOP
  4. 4

    Je crois, un avantage de plus est avec RejectionHandler. Corrigez-moi si mauvais

    InformationsquelleAutor Balaji Boggaram Ramanarayan
  5. 2

    Dans le premier exemple, Vous avez créé à seulement 20 threads avec la déclaration ci-dessous

    ExecutorService executor = Executors.newFixedThreadPool(20);

    Dans le deuxième exemple, vous avez mis le fil limites entre 20 to 2000

     ThreadPoolExecutor tpExecutor = new ThreadPoolExecutor(20, 2000, 0L, 
                                     TimeUnit.MILLISECONDS,threadPool);

    Plus de threads disponibles pour le traitement. Mais vous avez configuré la tâche de la file d'attente comme la surabondance de la file d'attente.

    ThreadPoolExecutor serait plus efficace si vous avez personnalisé la plupart ou la totalité de ci-dessous les paramètres. 

    ThreadPoolExecutor(int corePoolSize, 
               int maximumPoolSize, 
               long keepAliveTime, 
               TimeUnit unit, 
               BlockingQueue<Runnable> workQueue, 
               ThreadFactory threadFactory,
               RejectedExecutionHandler handler)

    RejectedExecutionHandler serait utile lorsque vous définissez max capacity for workQueue et le nombre de tâches qui ont été soumis à l'Exécuteur testamentaire sont plus que workQueue capacité.

    Regarder Rejeté section tâches dans ThreadPoolExecutor pour plus de détails.

    InformationsquelleAutor Ravindra babu
  6. 1

    Après 2 jours de GC out of memory exception, ThreadPoolExecutor m'a sauvé la vie. 🙂

    Comme Balaji dit,

    [..] un avantage de plus est avec RejectionHandler.

    Dans mon cas, j'ai eu beaucoup de RejectedExecutionException et en indiquant (à suivre) le rejet de la politique résolu tous mes problèmes.

    private ThreadPoolExecutor executor = new ThreadPoolExecutor(1, cpus, 1, TimeUnit.SECONDS, new SynchronousQueue<Runnable>(), new ThreadPoolExecutor.DiscardPolicy());

    Mais attention! Il ne fonctionne que si vous ne pas besoin pour exécuter tous les fils que vous soumettez à l'exécuteur testamentaire.

    Pour de plus amples informations sur ThreadPoolExecutor prendre un coup d'oeil à Darren réponse

    InformationsquelleAutor