Накладные расходы на создание потоков Java

Question

Традиционная мудрость говорит нам о том, что приложения большого объема для предприятий Java должны использовать объединение потоков, предпочитая создавать новые рабочие потоки. Использование java.util.concurrent делает это простым.

Однако существуют ситуации, когда объединение потоков не подходит. Конкретным примером, с которым я в настоящее время занимаюсь, является использование InheritableThreadLocal, которое позволяет передавать ThreadLocal переменным в любые порожденные потоки. Этот механизм прерывается при использовании пулов потоков, поскольку рабочие потоки, как правило, не генерируются из потока запросов, но уже существуют.

Теперь есть способы обойти это (локаторы потоков могут быть явно переданы), но это не всегда удобно или практично. Самое простое решение - порождать новые рабочие потоки по требованию, и пусть InheritableThreadLocal выполняет свою работу.

Это возвращает нас к вопросу - если у меня есть сайт с большим объемом, где потоки запросов пользователей порождают полдюжины рабочих потоков каждый (т. Е. Не используют пул потоков), это даст JVM a проблема? Мы потенциально говорим о создании нескольких сотен новых потоков каждую секунду, каждая из которых длится менее секунды. Могут ли современные JVM оптимизировать это? Я помню дни, когда объединение объектов было желательно в Java, потому что создание объекта было дорогостоящим. С тех пор это стало ненужным. Мне интересно, если это относится к пулу потоков.

Я бы оценил это, если бы знал, что измерить, но я боюсь, что проблемы могут быть более тонкими, чем можно измерить с помощью профилировщика.

Примечание: мудрость использования локаторов потоков не является проблемой здесь, поэтому, пожалуйста, не предлагайте, чтобы я не использовал их.

Answer 1

Вот пример microbenchmark:

public class ThreadSpawningPerformanceTest { 
static long test(final int threadCount, final int workAmountPerThread) throws InterruptedException { 
    Thread[] tt = new Thread[threadCount]; 
    final int[] aa = new int[tt.length]; 
    System.out.print("Creating "+tt.length+" Thread objects... "); 
    long t0 = System.nanoTime(), t00 = t0; 
    for (int i = 0; i < tt.length; i++) { 
     final int j = i; 
     tt[i] = new Thread() { 
      public void run() { 
       int k = j; 
       for (int l = 0; l < workAmountPerThread; l++) { 
        k += k*k+l; 
       } 
       aa[j] = k; 
      } 
     }; 
    } 
    System.out.println(" Done in "+(System.nanoTime()-t0)*1E-6+" ms."); 
    System.out.print("Starting "+tt.length+" threads with "+workAmountPerThread+" steps of work per thread... "); 
    t0 = System.nanoTime(); 
    for (int i = 0; i < tt.length; i++) { 
     tt[i].start(); 
    } 
    System.out.println(" Done in "+(System.nanoTime()-t0)*1E-6+" ms."); 
    System.out.print("Joining "+tt.length+" threads... "); 
    t0 = System.nanoTime(); 
    for (int i = 0; i < tt.length; i++) { 
     tt[i].join(); 
    } 
    System.out.println(" Done in "+(System.nanoTime()-t0)*1E-6+" ms."); 
    long totalTime = System.nanoTime()-t00; 
    int checkSum = 0; //display checksum in order to give the JVM no chance to optimize out the contents of the run() method and possibly even thread creation 
    for (int a : aa) { 
     checkSum += a; 
    } 
    System.out.println("Checksum: "+checkSum); 
    System.out.println("Total time: "+totalTime*1E-6+" ms"); 
    System.out.println(); 
    return totalTime; 
} 

public static void main(String[] kr) throws InterruptedException { 
    int workAmount = 100000000; 
    int[] threadCount = new int[]{1, 2, 10, 100, 1000, 10000, 100000}; 
    int trialCount = 2; 
    long[][] time = new long[threadCount.length][trialCount]; 
    for (int j = 0; j < trialCount; j++) { 
     for (int i = 0; i < threadCount.length; i++) { 
      time[i][j] = test(threadCount[i], workAmount/threadCount[i]); 
     } 
    } 
    System.out.print("Number of threads "); 
    for (long t : threadCount) { 
     System.out.print("\t"+t); 
    } 
    System.out.println(); 
    for (int j = 0; j < trialCount; j++) { 
     System.out.print((j+1)+". trial time (ms)"); 
     for (int i = 0; i < threadCount.length; i++) { 
      System.out.print("\t"+Math.round(time[i][j]*1E-6)); 
     } 
     System.out.println(); 
    } 
} 
} 

Результатов на 64-битной ОС Windows 7 с 32-разрядной компанией Sun Java 1.6.0_21 Client VM на E6400 Intel Core2 Duo @ 2.13 ГЦа следующим образом:

Number of threads 1 2 10 100 1000 10000 100000 
1. trial time (ms) 346 181 179 191 286 1229 11308 
2. trial time (ms) 346 181 187 189 281 1224 10651 

Выводы: два потока выполняют работу почти в два раза быстрее, чем один, как и ожидалось, так как мой компьютер имеет два ядра. Мой компьютер может генерировать почти 10000 потоков в секунду, т.е. е. Накладные расходы на создание потоков составляют 0,1 миллисекунды. Следовательно, на такой машине несколько сотен новых потоков в секунду создают незначительные накладные расходы (что также можно увидеть, сравнивая числа в столбцах для 2 и 100 потоков).

Answer 2

Прежде всего, это, конечно же, будет зависеть от того, на какой именно JVM вы используете. ОС также будет играть важную роль. Предполагая, что Sun JVM (Hm, мы все еще называем это?):

Одним из основных факторов является память стека, выделенная для каждого потока, которую вы можете настроить с помощью параметра JVM - вы захотите использовать самую низкую ценность, с которой вы можете избавиться.

И это всего лишь предположение, но я думаю, что «пара сотен новых потоков каждую секунду» определенно превышает то, что JVM предназначен для удобной работы. Я подозреваю, что простой тест быстро выявит довольно непростые проблемы.

Answer 3

• для ориентира можно использовать JMeter + профайлер, который должен дать вам прямой обзор поведения в такой тяжелой нагруженной среде. Просто позвольте ему работать в течение часа и следить за памятью, процессором и т. Д. Если ничего не сломается, и CPU не перегревается, это нормально :)

• возможно, вы можете получить пул потоков или настроить (продлить) тот, который вы используете, добавив некоторый код для того, чтобы каждый InheritableThreadLocal s устанавливался каждый раз, когда Thread получен из пула потоков. Каждый Thread имеет следующие пакет-частные свойства:

  /* ThreadLocal values pertaining to this thread. This map is maintained 
  * by the ThreadLocal class. */ 
  ThreadLocal.ThreadLocalMap threadLocals = null; 
  
  /* 
  * InheritableThreadLocal values pertaining to this thread. This map is 
  * maintained by the InheritableThreadLocal class. 
  */ 
  ThreadLocal.ThreadLocalMap inheritableThreadLocals = null; 
  

  Вы можете использовать эти (хорошо, с отражением) в сочетании с Thread.currentThread() иметь желаемое поведение. Однако это немного ад-скакалка, и, кроме того, я не могу сказать, не отразится ли это (с отражением) даже большие накладные расходы, чем просто создание потоков.

Answer 4

Мне интересно, нужно ли создавать новые потоки для каждого пользовательского запроса, если их типичный жизненный цикл является коротким, как секунда. Не могли бы вы использовать какую-то очередь Notify/Wait, в которой вы порождаете заданное количество потоков (daemon), и все они ждут, пока не будет решена задача. Если очередь задач становится длинной, вы создаете дополнительные потоки, но не в соотношении 1-1. Скорее всего, это будет лучше, чем порождать сотни новых потоков, жизненные циклы которых настолько коротки.