1) Оцените вашу заявку в целом. Не думайте, что вы знаете, где находятся узкие места в вашем приложении. Опыт показывает снова и снова и снова, что люди обычно сосут это. Делайте это на оборудовании и системах, которые идентичны производственным, или вы тратите свое время.
2) Не забудьте структурировать свой тест таким образом, чтобы компилятор JIT включил код, который вас интересует. 10000 итераций метода обычно необходимы перед компиляцией метода. Сравнительный анализ кода в интерпретируемом режиме - это пустая трата времени.
3) В приложении, где были устранены наиболее существенные узкие места, многие приложения будут находиться в состоянии, в котором в профиле производительности преобладает число пропусков кэш-памяти процессора L1. Вы можете рассматривать это как точку, в которой ваше приложение достаточно хорошо настроено. Тем не менее, ваши алгоритмы могут по-прежнему отстой, и в системе все еще может быть много занятой работы, от которой вы можете избавиться.
4) Предполагая, что ваши алгоритмы не отстой и у вас нет больших кусков занятой работы, от которых вы можете избавиться, если разница между массивами и списками действительно значительна для вас, то в этот момент вы начнете чтобы увидеть это в цифрах.
5) В большинстве случаев вы обнаружите, что ситуация с кэшем L1 будет лучше для массивов, чем для списков. Тем не менее, это общий совет, который нельзя ошибочно принять за реальный совет по настройке производительности. Сгенерируйте свои числа и проанализируйте их.
tl; dr version : Читать длинную версию. Д-ру не место в обсуждении производительности Java - это тонкие и сложные вещи, и нюансы имеют значение.