Блог

Контекст

Я рассматриваю пару клиентов Java Redis, таких как Lettuce и Jedis. Я вижу, что обе библиотеки определили свои методы для возврата упакованных примитивных типов, а не прямых примитивов.

Например, sadd() возвращает Long , а не просто long . https://lettuce.io/lettuce-4/release/api/com/lambdaworks/redis/api/sync/RedisSetCommands.html#sadd-K-V…-
и
https://github.com/xetorthio/jedis/blob/d7aba13a8b65e66dedc01c51b73e3794cbe68a62/src/main/java/redis/clients/jedis/commands/BinaryJedisCommands.java#L139

Вопрос

Что может быть причиной возврата упакованных примитивов?
Насколько я понимаю, боксирование увеличивает накладные расходы на производительность.

Имеет ли смысл для моей библиотеки, которая использует библиотеку Redis, сохранять возвращаемые значения в штучной упаковке и распространять их среди пользователей библиотеки?

Редактировать: Ни один из методов не возвращает null , поэтому кодирование особого значения в null к ним не применяется.

На мой взгляд, основная причина заключается в возможности извлечения Object вместо примитивного типа. Например. это возможно для извлечения null .

Числовые оболочки, такие как Integer , Long …, являются кэшированными значениями между -128; 127 . Все остальные значения будут дублироваться в памяти. Более того, для хранения Long требуется в 3 раза больше места, чем для хранения long .

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

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