Играя с многопоточностью, я мог наблюдать некоторые неожиданные, но серьезные проблемы с производительностью, связанные с AtomicLong (и классами, использующими его, такими как java.util.Random), которым я в настоящее время не могу объяснить. Однако я создал минималистичный пример, который в основном состоит из двух классов: класса «Контейнер», который хранит ссылку на переменную, и класса «DemoThread», который работает с экземпляром «Контейнера» во время выполнения потока. Обратите внимание, что ссылки на «Container» и volatile long являются частными и никогда не разделяются между потоками (я знаю, что нет необходимости использовать volatile здесь, это просто для демонстрационных целей) - таким образом, несколько экземпляров «DemoThread» должны работать идеально параллельны на многопроцессорных машинах, но по какой-то причине их нет (полный пример находится внизу этого поста).
private static class Container {
private volatile long value;
public long getValue() {
return value;
}
public final void set(long newValue) {
value = newValue;
}
}
private static class DemoThread extends Thread {
private Container variable;
public void prepare() {
this.variable = new Container();
}
public void run() {
for(int j = 0; j < 10000000; j++) {
variable.set(variable.getValue() + System.nanoTime());
}
}
}
Во время теста я многократно создаю 4 DemoThreads, которые затем запускаются и объединяются. Единственное отличие в каждом цикле - это время, когда вызывается метод prepare () (что, очевидно, требуется для выполнения потока, так как в противном случае это приведет к исключению NullPointerException):
DemoThread[] threads = new DemoThread[numberOfThreads];
for(int j = 0; j < 100; j++) {
boolean prepareAfterConstructor = j % 2 == 0;
for(int i = 0; i < threads.length; i++) {
threads[i] = new DemoThread();
if(prepareAfterConstructor) threads[i].prepare();
}
for(int i = 0; i < threads.length; i++) {
if(!prepareAfterConstructor) threads[i].prepare();
threads[i].start();
}
joinThreads(threads);
}
По какой-то причине, если prepare () выполняется непосредственно перед запуском потока, для его завершения потребуется вдвое больше времени, и даже без ключевого слова "volatile" различия в производительности были значительными, по крайней мере, для двух из машины и ОС я тестировал код. Вот краткое резюме:
Mac OS Резюме:
Версия Java: 1.6.0_24
Версия Java Class: 50.0
Поставщик VM: Sun Microsystems Inc.
Версия VM: 19.1-b02-334
Имя виртуальной машины: Java HotSpot (TM) 64-битный сервер VM
Название ОС: Mac OS X
ОС Arch: x86_64
Версия ОС: 10.6.5
Процессоры / ядер: 8
С изменчивым ключевым словом:
Окончательные результаты:
31979 мс когда prepare () вызывается после создания экземпляра.
96482 мс когда prepare () вызывается перед выполнением.
Без изменяемого ключевого слова:
Окончательные результаты:
26009 мс когда prepare () вызывается после создания экземпляра.
35196 мс когда prepare () вызывается перед выполнением.
Обзор Windows:
Java версия: 1.6.0_24
Версия Java Class: 50.0
Поставщик VM: Sun Microsystems Inc.
Версия VM: 19.1-b02
Имя виртуальной машины: Java HotSpot (TM) 64-битный сервер VM
Название ОС: Windows 7
ОС Arch: amd64
Версия ОС: 6.1
Процессоры / ядра: 4
С изменчивым ключевым словом:
Окончательные результаты:
18120 мс когда prepare () вызывается после создания экземпляра.
36089 мс когда prepare () вызывается перед выполнением.
Без изменяемого ключевого слова:
Окончательные результаты:
10115 мс когда prepare () вызывается после создания экземпляра.
10039 мс когда prepare () вызывается перед выполнением.
Linux Summary:
Java версия: 1.6.0_20
Версия Java Class: 50.0
Поставщик VM: Sun Microsystems Inc.
Версия ВМ: 19.0-b09
Имя виртуальной машины: 64-битный сервер OpenJDK VM
Название ОС: Linux
ОС Arch: amd64
Версия ОС: 2.6.32-28-generic
Процессоры / Ядра: 4
С изменчивым ключевым словом:
Окончательные результаты:
45848 мс когда prepare () вызывается после создания экземпляра.
110754 мс когда prepare () вызывается перед выполнением.
Без изменяемого ключевого слова:
Окончательные результаты:
37862 мс когда prepare () вызывается после создания экземпляра.
39357 мс когда prepare () вызывается перед выполнением.
Сведения о Mac OS (энергозависимые):
Тест 1, 4 потока, установка переменной в цикле создания
Поток-2 завершен через 653 мс.
Поток-3 завершен через 653 мс.
Поток-4 завершен через 653 мс.
Поток-5 завершен через 653 мс.
Общее время: 654 мс.
Тест 2, 4 потока, установка переменной в цикле запуска
Тема 7 завершена через 1588 мс.
Тема 6 завершена через 1589 мс.
Поток-8 завершен после 1593 мс.
Поток-9 завершен после 1593 мс.
Общее время: 1594 мс.
Тест 3, 4 потока, установка переменной в цикле создания
Поток-10 завершен через 648 мс.
Поток-12 завершен через 648 мс.
Поток-13 завершен через 648 мс.
Поток-11 завершен через 648 мс.
Общее время: 648 мс.
Тест 4, 4 потока, установка переменной в цикле запуска
Поток-17 завершен через 1353 мс.
Поток-16 завершен после 1957 мс.
Поток-14 завершен через 2170 мс.
Тема 15 завершена через 2169 мс.
Общее время: 2172 мс.
(и так далее, иногда один или два потока в «медленном» цикле завершаются, как и ожидалось, но в большинстве случаев этого не происходит).
Данный пример выглядит теоретически, какон бесполезен, и «volatile» здесь не нужен - однако, если бы вы использовали «java.util.Random» -Instance вместо «Container» -Class и вызывали, например, nextInt (), несколькоИногда будут происходить те же эффекты: поток будет выполняться быстро, если вы создадите объект в конструкторе потока, но медленный, если вы создадите его в методе run ().Я считаю, что проблемы с производительностью, описанные в Java Random Slowdowns в Mac OS более года назад, связаны с этим эффектом, но я понятия не имею, почему это так - кроме того, что я уверен, чтоэто не должно быть так, поскольку это будет означать, что всегда опасно создавать новый объект в методе выполнения потока, если только вы не знаете, что в графе объектов не будут задействованы переменные.Профилирование не помогает, так как в этом случае проблема исчезает (то же самое наблюдение, что и в Случайные замедления Java в Mac OS продолжение ), и это также не происходит на одноядерном ПК - такЯ предполагаю, что это своего рода проблема синхронизации потоков ... однако странно то, что на самом деле синхронизировать нечего, поскольку все переменные являются локальными для потоков.
Действительно ожидаем любых подсказок - ина всякий случай, если вы хотите подтвердить или сфальсифицировать проблему, см. контрольный пример ниже.
Спасибо,
Стефан
public class UnexpectedPerformanceIssue {
private static class Container {
// Remove the volatile keyword, and the problem disappears (on windows)
// or gets smaller (on mac os)
private volatile long value;
public long getValue() {
return value;
}
public final void set(long newValue) {
value = newValue;
}
}
private static class DemoThread extends Thread {
private Container variable;
public void prepare() {
this.variable = new Container();
}
@Override
public void run() {
long start = System.nanoTime();
for(int j = 0; j < 10000000; j++) {
variable.set(variable.getValue() + System.nanoTime());
}
long end = System.nanoTime();
System.out.println(this.getName() + " completed after "
+ ((end - start)/1000000) + " ms.");
}
}
public static void main(String[] args) {
System.out.println("Java Version: " + System.getProperty("java.version"));
System.out.println("Java Class Version: " + System.getProperty("java.class.version"));
System.out.println("VM Vendor: " + System.getProperty("java.vm.specification.vendor"));
System.out.println("VM Version: " + System.getProperty("java.vm.version"));
System.out.println("VM Name: " + System.getProperty("java.vm.name"));
System.out.println("OS Name: " + System.getProperty("os.name"));
System.out.println("OS Arch: " + System.getProperty("os.arch"));
System.out.println("OS Version: " + System.getProperty("os.version"));
System.out.println("Processors/Cores: " + Runtime.getRuntime().availableProcessors());
System.out.println();
int numberOfThreads = 4;
System.out.println("\nReference Test (single thread):");
DemoThread t = new DemoThread();
t.prepare();
t.run();
DemoThread[] threads = new DemoThread[numberOfThreads];
long createTime = 0, startTime = 0;
for(int j = 0; j < 100; j++) {
boolean prepareAfterConstructor = j % 2 == 0;
long overallStart = System.nanoTime();
if(prepareAfterConstructor) {
System.out.println("\nTest " + (j+1) + ", " + numberOfThreads + " threads, setting variable in creation loop");
} else {
System.out.println("\nTest " + (j+1) + ", " + numberOfThreads + " threads, setting variable in start loop");
}
for(int i = 0; i < threads.length; i++) {
threads[i] = new DemoThread();
// Either call DemoThread.prepare() here (in odd loops)...
if(prepareAfterConstructor) threads[i].prepare();
}
for(int i = 0; i < threads.length; i++) {
// or here (in even loops). Should make no difference, but does!
if(!prepareAfterConstructor) threads[i].prepare();
threads[i].start();
}
joinThreads(threads);
long overallEnd = System.nanoTime();
long overallTime = (overallEnd - overallStart);
if(prepareAfterConstructor) {
createTime += overallTime;
} else {
startTime += overallTime;
}
System.out.println("Overall time: " + (overallTime)/1000000 + " ms.");
}
System.out.println("Final results:");
System.out.println(createTime/1000000 + " ms. when prepare() was called after instantiation.");
System.out.println(startTime/1000000 + " ms. when prepare() was called before execution.");
}
private static void joinThreads(Thread[] threads) {
for(int i = 0; i < threads.length; i++) {
try {
threads[i].join();
} catch (InterruptedException e) {
e.printStackTrace();
}
}
}
}