Задержка выделения кажется высокой, почему?

Поскольку ваш вопрос был больше о том, как исследовать проблему, а не о том, в чем моя проблема, я воспользуюсь некоторыми инструментами, чтобы попробовать.

Очень полезный инструмент для получить лучшее представление о том, что происходит и когда - BTrace . Он похож на DTrace, но представляет собой чистый java-инструмент. В связи с этим я предполагаю, что вы знакомы с DTrace, если нет, это тоже полезно, если не тупо. Это даст вам некоторое представление о том, что и когда происходит в JVM и ОС.

О, еще одна вещь, которую нужно уточнить в исходной публикации. Какой у вас коллектор? Я предполагаю, что из-за проблемы с высокой задержкой вы используете сборщик с низкой паузой, такой как CMS. Если да, то пробовали ли вы какую-нибудь настройку?

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

Вы отдельно рассчитали время, необходимое для создания новых списков массивов?

Вероятно, нет никакой надежды на ожидание микросекунды. - гарантии задержки от виртуальной машины общего назначения, работающей в ОС общего назначения, даже с таким отличным оборудованием. Большая пропускная способность - лучшее, на что вы можете надеяться. Как насчет переключения на виртуальную машину реального времени, если она вам нужна (я говорю о RTSJ и , все это ...)

... мои два цента

Просто некоторые дикие догадки:

Насколько я понимаю, Java VMs обрабатывают память короткоживущих объектов иначе, чем длинные объекты. Мне кажется разумным, что в тот момент, когда объект переходит от одной функции-локальной ссылки к ссылке в глобальной куче, это будет большим событием. Вместо того, чтобы быть доступным для очистки при выходе из функции, теперь его должен отслеживать ГХ.

Или может быть так, что переход от одной ссылки к нескольким ссылкам на один объект должен изменить учет в ГХ. Пока объект имеет одну ссылку, его легко очистить. Несколько ссылок могут иметь циклы ссылок и/или ГХ может быть вынуждена искать ссылку во всех других объектах

Когда вы повторяете одну и ту же задачу много раз, ваш процессор, как правило, работает очень эффективно. Это происходит потому, что ваш кэш пропускает время и разогрев процессора не появляется как фактор. Это также возможно, что вы не учитываете ваше JVM теплое время тоже.

Если вы попробуете то же самое, когда JVM и/или процессор не разогревается. Вы получите совсем другие результаты.

Попробуйте сделать то же самое, скажем 25 раз (меньше, чем ваш порог компиляции) и спать(100) между тестами. Вы должны ожидать, что увидите намного больше раз, ближе к тому, что вы видите в реальном приложении.

Поведение вашего приложения будет отличаться, но чтобы проиллюстрировать мою точку зрения. Я обнаружил, что ожидание ввода-вывода может быть более разрушительным, чем простой сон.

Когда вы выполняете свой бенчмарк, вы должны попытаться убедиться, что вы сравниваете, как с "как".

import java.io.*;
import java.util.Date;

/**
Cold JVM with a Hot CPU took 123 us average
Cold JVM with a Cold CPU took 403 us average
Cold JVM with a Hot CPU took 314 us average
Cold JVM with a Cold CPU took 510 us average
Cold JVM with a Hot CPU took 316 us average
Cold JVM with a Cold CPU took 514 us average
Cold JVM with a Hot CPU took 315 us average
Cold JVM with a Cold CPU took 545 us average
Cold JVM with a Hot CPU took 321 us average
Cold JVM with a Cold CPU took 542 us average
Hot JVM with a Hot CPU took 44 us average
Hot JVM with a Cold CPU took 111 us average
Hot JVM with a Hot CPU took 32 us average
Hot JVM with a Cold CPU took 96 us average
Hot JVM with a Hot CPU took 26 us average
Hot JVM with a Cold CPU took 80 us average
Hot JVM with a Hot CPU took 26 us average
Hot JVM with a Cold CPU took 90 us average
Hot JVM with a Hot CPU took 25 us average
Hot JVM with a Cold CPU took 98 us average
 */
public class HotColdBenchmark {
    public static void main(String... args) {
        // load all the classes.
        performTest(null, 25, false);
        for (int i = 0; i < 5; i++) {
            // still pretty cold
            performTest("Cold JVM with a Hot CPU", 25, false);
            // still pretty cold
            performTest("Cold JVM with a Cold CPU", 25, true);
        }

        // warmup the JVM
        performTest(null, 10000, false);
        for (int i = 0; i < 5; i++) {
            // warmed up.
            performTest("Hot JVM with a Hot CPU", 25, false);
            // bit cold
            performTest("Hot JVM with a Cold CPU", 25, true);
        }
    }

    public static long performTest(String report, int n, boolean sleep) {
        long time = 0;
        long ret = 0;
        for (int i = 0; i < n; i++) {
            long start = System.nanoTime();
            try {
                ByteArrayOutputStream baos = new ByteArrayOutputStream();
                ObjectOutputStream oos = new ObjectOutputStream(baos);
                oos.writeObject(new Date());
                oos.close();
                ObjectInputStream ois = new ObjectInputStream(new ByteArrayInputStream(baos.toByteArray()));
                Date d = (Date) ois.readObject();
                ret += d.getTime();
                time += System.nanoTime() - start;
                if (sleep) Thread.sleep(100);
            } catch (Exception e) {
                throw new AssertionError(e);
            }
        }
        if (report != null) {
            System.out.printf("%s took %,d us average%n", report, time / n / 1000);
        }
        return ret;
    }
}