Какой использовать, int или Integer

Integer теоретически медленнее, чем int, однако влияние на производительность должно быть минимальным, если только вы не гадите числа. Также оптимизация JIT снизит потерю производительности.

Используйте тот, который лучше подходит для вашей ситуации с точки зрения примитивного или ссылочного типа.

Integer - лучший вариант, так как он может работать с null; для int, null станет 0 незаметно, если используется resultSet.getInt(..). В противном случае может возникнуть исключение, например «Невозможно установить для null примитивное свойство».

Производительность здесь не имеет большого значения.

• если вы выберете int, вы в конечном итоге добавите дополнительный код обработки; и это не принесет вам большой пользы. Ваш код не будет чистым и прямым, много шаблонного кода, и вы даже не получите повышения производительности.
• позвольте мне прояснить, что для баз данных значение null не равно нулю. Иногда вы попадаете в 0, где предназначалась null. Представьте себе случай, когда пользователь отправил форму и не предоставил никакого значения для int. По умолчанию вы получите 0. Это имеет смысл, или действительно имеет смысл, когда это поле в базе данных - not null.

Я предполагаю, что это зависит, среди прочего, от того, что вы используете для доступа к базе данных. С простым старым JDBC вы могли бы работать с int, в то время как ORM все равно мог молча конвертировать их в Integers. И Integer позволит вам обрабатывать нули.

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

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

• Integer может быть null, int - нет. Так является ли int в БД полем Nullable?
• Вам нужен доступ к методам класса Integer?
• Вы занимаетесь арифметикой?

Лично я всегда предпочитаю обертку примитиву. Но это всего лишь предпочтение, а не какие-либо технические достоинства.

На мой взгляд, выбор между объявлением чего-либо как int или Integer просто сводится к тому, является ли null допустимым для него значением или нет. Autoboxing (и autounboxing) позаботится о любых проблемах с преобразованием, когда число просто должно быть того или иного типа. Производительность (как уже указывалось) также вряд ли будет заметной почти во всех случаях.

Кроме того, тип int должен быть естественным выбором и, вероятно, будет наиболее производительным, если это все равно будет проблемой. Если вам нужно иметь возможность хранить нули, тогда вы имеют используете Integer (а также убедитесь, что никакие нулевые ссылки не распаковываются автоматически для метода, который принимает просто целые числа, поскольку это приведет к исключению NullPointerException).

Чтобы дать вам представление, 2000 Integer добавит к вашему запросу около 0,5 мс. Если вам нужно сериализовать эти данные, это может добавить немного больше.

Однако правильность должна быть на первом месте. Нет смысла быть очень быстрым, но ошибаться. Вы должны учитывать нулевые значения и то, как вы их обрабатываете. (Если столбец НЕ НЕДЕЙСТВИТЕЛЕН) Вы можете использовать Integer.MIN ___ VALUE или вы можете использовать поле длинный вместо int и использовать Long.MIN_VALUE для null. Несмотря на то, что он больше, чем int, он все равно будет во много раз меньше и эффективнее, чем Integer.

int в 10 раз быстрее, чем целое

мы тестируем этот код с библиотекой производительности jetm

int n;
EtmPoint point1 = etmMonitor.createPoint("test:objects");
for (n = 0; n < 1000000; n++) {
    Integer t = 0;
    t = 10;
    t = 11;
}

point1.collect();
EtmPoint point = etmMonitor.createPoint("test:primitives");
for (n = 0; n < 1000000; n++) {
    int t = 0;
    t = 10;
    t = 11;
}
point.collect();

etmMonitor.render(new SimpleTextRenderer());

и результаты:
тест:объекты 10.184
тест: примитивы 1.151

int нельзя транслировать на String с использованием toString или (String).

Integer может транслировать в String с toString или (String), и он может обрабатывать null.

int используется Java для большинства вычислений. Integer используется во всех формах Коллекций, кроме примитивных массивов.

Использование большого количества временных целых чисел со сборщиком мусора и использование непрофильного процессора в фоновом режиме, что вызовет общее замедление во всем. Слишком большое количество временных файлов, удаляемых в секунду, приведет к тому, что CG перейдет в аварийный режим «Мне нужна память сейчас», что может вызвать сбои в работе приложений, критичных к задержке (например: интерактивная графика в реальном времени, контроллеры физических устройств или связь)

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

Если операции являются математическими или используются в качестве счетчиков циклов или других математических операций и не хранятся в коллекциях (кроме примитивных массивов), я использую примитив. То же самое и со всеми другими примитивами, кроме String, который является полноценным объектом.

Если вы хотите проверить значение null, лучше всего подходит Integer, но если вы хотите сравнить целое число, лучше int. В следующем примере я использую целое число c = 1000 и d = 1000 и сравниваю его, возвращая false, но в случае int они вернут true.

public class IntegerCompare {

    public static void main(String[] args) {
        int a = 1000;
        int b = 1000;

        Integer c = 1000;
        Integer d = 1000;

        if (a == b) {
            System.out.println("int Value Equals");

        }
        if (c == d) {
            System.out.println("Integer value Equals");

        } else {

            System.out.println("Integer Value Not Equals");
        }
    }
}

Один из возможных сценариев - проверка.

Представьте, что у нас есть следующий класс:

class Foo{
    @Min(value = 10)
    int val;
}

Если пользователь не укажет значение для val в запросе, мы получим неприятный NumberFormatException.

Если int заменить на Integer, мы можем использовать @NotNull и решить эту проблему более изящно.