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

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

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

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

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

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

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

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

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

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;
    }
}

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

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

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

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

Одни дикие догадки:

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

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