Мне нужно создать объект передачи данных, который я буду использовать для хранения записей, извлеченных из базы данных. В этом объекте передачи данных мне нужно объявить числовое поле. Для того, что лучше - int или Целое
Если я определяю поле как целое, будет ли какое-либо влияние на производительность из-за типа Integer, если я собираюсь извлечь более 2000 записей из базы данных??
Спасибо заранее.
Integer - лучший вариант, поскольку он может обрабатывать null; для int, null станет 0, молча, если используется resultSet.getInt(..). В противном случае это может вызвать какое-то исключение, например: "Невозможно установить null в свойство примитива".
Производительность здесь не особо важна.
int, вы добавите дополнительный код обработки; и это не принесет вам много пользы. Ваш код не будет чистым и прямым, много кода котельной, и вы даже не получите производительности.0, где предназначался null. Представьте себе случай, когда пользователь отправил форму, и не дает никакого значения для int. По умолчанию вы получите 0. Это имеет смысл или действительно, когда это поле not null в базе данных.Вы должны действительно принять решение на основе того, что вам нужно, чтобы ваш объект работал, а не затраты на производительность. Решение, основанное на производительности, должно быть выполнено, как только проблема скорости была идентифицирована с профилировщиком - корнем всех зла и всего этого.
Посмотрите на некоторые из возможностей обоих и используйте это для своего решения, например
Integer может быть null, int не может. Итак, int в поле DB a Nullable?Integer?Лично я всегда выбираю примитив над оболочкой. Но это только предпочтение, а не на основе каких-либо технических достоинств.
На мой взгляд, выбор между объявлением чего-либо как int или Integer просто сводится к тому, является ли null допустимым значением для него или нет. Autoboxing (и autounboxing) будет заботиться о любых проблемах преобразования, где число просто должно быть одного типа. Производительность (как было указано) также вряд ли будет заметна почти во всех случаях.
Кроме того, int должен быть естественным выбором и, вероятно, будет самым результативным, если это будет проблемой в любом случае. Если вам нужно иметь возможность сохранять значения NULL, то у вас есть, чтобы использовать Integer (а также гарантировать, что никакие нулевые ссылки не будут автоматически распакованы для метода, который использует просто ints, так как это приведет к исключению NullPointerException).
Integer теоретически медленнее, чем int, однако влияние производительности должно быть минимальным, если вы не хрустаете цифры. Также оптимизация JIT уменьшит потерю производительности.
Используйте тот, который лучше подходит для вашей ситуации с точки зрения примитивного или ссылочного типа.
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());
и результаты:
test: объекты 10.184
тест: примитивы 1.151
Чтобы дать вам представление, 2000 Integer добавит к вашему запросу около 0,5 мс. Если вам нужно сериализовать эти данные, он может добавить еще немного.
Однако правильность должна быть первой. Нет смысла быть очень быстрым, но неправильным. Вы должны учитывать нулевые значения и способы их обработки. (Если столбец NOT NULL), вы можете использовать Integer.MIN ___ VALUE или использовать длинное поле вместо int и использовать Long.MIN_VALUE для значения null. Хотя он больше, чем int, он все равно будет во много раз меньше и эффективнее Integer.
Я предполагаю, что это зависит, помимо прочего, от того, что вы используете для доступа к базе данных. С обычным старым JDBC вы можете делать с int s, в то время как ORM может молча преобразовать их в Integers в любом случае. И Integer позволит вам обрабатывать нули.
int используется Java для большинства всех вычислений. Integer используется во всех формах коллекций, кроме примитивных массивов.
Использование большого количества временных целых чисел с трэш-сборщиком мусора и использование непроизводительного процессора в фоновом режиме, что вызовет общее замедление во всем. Слишком большое количество временных загрузок в секунду приведет к тому, что CG перейдет в аварийный режим "Мне нужна память сейчас", что может привести к задержкам в критически важных приложениях (например, интерактивная графика в реальном времени, контроллеры физических устройств или связь).
Так что для меня, если у меня много вложенных вызовов, которые не занимаются математикой, но имеют доступ ко многим коллекциям, таким как использование ключей для карт, я использую Integer, чтобы избежать тонн автоматического бокса при передаче аргументов.
Если операции интенсивны по математике или используются как счетчики циклов или другие математические операции и не хранятся в коллекциях (кроме примитивных массивов), я использую примитив. То же самое относится ко всем другим примитивам, кроме String, который является полноценным объектом.
int нельзя использовать для String с помощью toString или (String).
Integer может использоваться для String с toString или (String) и может обрабатывать null.
Если вы хотите проверить значение null, тогда Integer лучше, но если вы хотите сравнить целое число, тогда int может быть лучше. В следующем примере я использую integer c = 1000 и d = 1000 и сравниваю его return 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 и решить эту проблему более изящно.