Рваные деньги почему double и float не подходят для финансов в Java

В разработке на Java термин «рваные деньги» — это профессиональный сленг, описывающий потерю точности, ошибки округления и накопление «мусора» в младших разрядах при использовании типов с плавающей точкой (float, double) для хранения денежных сумм. Как показывает практика и обсуждения на Stack Overflow, SQL.ru и в статьях экспертов (включая Джошуа Блоха, автора Effective Java), игнорирование этой проблемы приводит к критическим багам в биллинге, торговле и учетных системах.

Данная статья подробно разбирает, почему double — враг финансов, какие альтернативы существуют (long, BigDecimal, JSR-354/Java Money) и как правильно архитектурировать код, чтобы деньги оставались целыми.

Проблема: Почему double и float не подходят для денег

Многие новички (и не только) интуитивно выбирают double для цен: «Цена 1.005 — идеально влезает в double». Однако стандарт IEEE 754, лежащий в основе этих типов, представляет числа в двоичной системе счисления. Большинство десятичных дробей (0.1, 0.01, 1.005) в двоичной системе являются периодическими дробями и не могут быть представлены точно.

Классический пример ошибки

double price = 1.005;
double discount = 0.05; // 5%
double result = price — (price * discount); 
// Ожидаем: 0.95475
// Реальность: 0.9547499999999999 или 0.9547500000000001

В контексте высоконагруженных систем (например, Algo/DMA торговли, где валидируются ордера по ценовым лимитам +/- 5% от текущей цены), такие погрешности приводят к:

• Отклонению валидных ордеров (False Negative).
• Прохождению невалидных ордеров (False Positive).
• Расхождения в отчетах и реестрах (Reconciliation errors).

Цитата Джошуа Блоха (Effective Java): «Типы float и double предназначены для научных и инженерных расчетов… Не используйте их для денежных расчетов, если требуются точные значения»;

Решение №1: Целочисленная арифметика (long / int)

Самый производительный и простой подход — хранить деньги в минимальных неделимых единицах (копейках, центах, сатоши) в типе long.

Принцип работы

1. Входящая сумма (100.50 руб.) умножается на 100 → 10050L.
2. Все расчеты (сложение, вычитание, умножение на целое) происходят в long.
3. Деление выполняется с осторожностью (см. округление ниже).
4. При выводе делим на 100.0 и форматируем.

Преимущества и ограничения

Совет с Reddit (r/java): «Честно говоря, просто используйте целые числа для всего, что связано с деньгами, а потом форматируйте, когда показываете данные».

Решение №2: BigDecimal — Стандарт де-факто для Enterprise

Когда нужны сложные финансовые формулы (проценты, амортизация, налоги), long становится неудобен. java.math.BigDecimal — это неизменяемый (immutable) класс для точной десятичной арифметики с произвольной точностью.

Ключевые правила использования

• Только String-конструктор: new BigDecimal("1.005"). Никогда new BigDecimal(1.005) (double-конструктор переносит ошибку представления).
• Обязательное указание MathContext или scale при делении: Деление может дать бесконечную дробь (1/3). Без настройки округления бросит ArithmeticException.
• Используйте RoundingMode.HALF_EVEN (Banker’s Rounding) для банковских расчетов или HALF_UP для коммерческих.

Пример корректного кода

import java.math.BigDecimal;
import java.math.RoundingMode;

public class MoneyCalc {

 // Скаляр для хранения копеек (scale=2)
 private static final int SCALE = 2;
 private static final RoundingMode MODE = RoundingMode.HALF_EVEN;

 public static BigDecimal applyDiscount(BigDecimal price, BigDecimal discountPercent) {
 // price * (1 ౼ discount/100)
 BigDecimal one = BigDecimal.ONE;
 BigDecimal hundred = new BigDecimal("100");
 
 BigDecimal multiplier = one.subtract(discountPercent.divide(hundred, SCALE + 4, MODE));
 return price.multiply(multiplier).setScale(SCALE, MODE);
 }
}

Решение №3: JSR-354 (Java Money API) — Современный стандарт

Начиная с 2019 года (статья «От float до JSR-354» на Альта-Системс), индустрия переходит на стандарт JSR-354: Money and Currency API. Реализации: Moneta (Reference Implementation), JavaMoney.

Почему это лучше BigDecimal вручную?

1. Типобезопасность: Нельзя сложить рубли с долларами без явного конвертера.
2. Инкапсуляция валюты: Объект MonetaryAmount знает свою валюту, точность и правила округления.
3. Локализация: Готовое форматирование под локаль пользователя.
4. Конвертация: Встроенная поддержка провайдеров курсов валют (ExchangeRateProvider).

Пример использования (Moneta)

import javax.money.Monetary;
import javax.money.MonetaryAmount;
import org.javamoney.moneta.Money;
import org.javamoney.moneta.function.MonetaryOperators;

// Создание суммы
MonetaryAmount price = Money.of(100.50, "RUB"); // Безопасно: фабрика парсит строку/BigDecimal

// Округление по правилам валюты (для RUB это 2 знака, HALF_EVEN)
MonetaryAmount rounded = price.with(MonetaryOperators.rounding);

// Конвертация (требует настроенного провайдера курсов)
// MonetaryAmount inUSD = price.with(MonetaryConversions.getConversion("USD"));

Примечание: Для подключения в Maven/Gradle нужны зависимости javax.money:money-api и org.javamoney:moneta.

Специализированные библиотеки: Joda-Money

До появления JSR-354 де-факто стандартом была Joda-Money (от создателей Joda-Time); Она легче, не требует модульной системы JPMS (Java Modules) и отлично работает на Java 8+.

• Класс Money (immutable).
• Мощный API для расчетов: multipliedBy, dividedBy с режимами округления.
• Хорошая интеграция со Spring, Jackson, Hibernate.

Работа с БД: Как хранить в SQL

Ошибка в Java часто начинается со схемы БД.

• НЕ ПРАВИЛЬНО: FLOAT, DOUBLE PRECISION, REAL — те же проблемы IEEE 754.
• ПРАВИЛЬНО (Стандарт): NUMERIC(19, 4) или DECIMAL(19, 4). Точная математика на стороне БД;
• ПРАВИЛЬНО (Highload/NoSQL): BIGINT (хранение в минорных единицах). Максимальная скорость чтения/записи.

При маппинге (Hibernate/JPA):

// Для BigDecimal
@Column(precision = 19, scale = 4)
private BigDecimal amount;

// Для Long (копейки)
@Column(name = "amount_minor")
private Long amountMinor;

Важный нюанс: Округление (Rounding Modes)

«Рваные деньги» часто появляются именно на границе округления. Выбор режима, бизнес-решение, а не техническое.

Золотое правило: Округляйте только в самом конце цепочки вычислений (при сохранении в БД или выводе на экран). Промежуточные результаты храните с повышенной точностью (scale + 2..4).

Физические «рваные деньги» (Оффтоп, но важно)

Если тема статьи подразумевала буквально поврежденные купюры (на острове Ява или в РФ):

Согласно РосКачеству и инструкциям ЦБ РФ: сильно поврежденные купюры (с потерянными фрагментами, обгоревшие, порванные на куски) в магазинах не принимают. Их можно обменять в любом банке-кредитной организации, если сохранено не менее 55% площади купюры. Если меньше — подлежат утилизации.

Чек-лист: Как не получить «рваные деньги» в проекте

1. Аудит кода: Поиск double/float в DTO, Entity, Service слоях, связанных с деньгами.
2. Единый подход: Выберите один: long (highload/простые расчеты) ИЛИ BigDecimal/Money API (сложная логика). Не смешивайте без явного маппинга.
3. Value Object: Создайте класс Money / Amount, инкапсулирующий логику (как в задаче CS50 «Greedy» или примерах на Киберфоруме). Запретите примитивы в публичном API.
4. Тесты на границы: Проверьте 0.005, 0.015, большие суммы (overflow long), деление на 3, 7.
5. Миграция БД: Убедитесь, что колонки NUMERIC/DECIMAL или BIGINT.
6. JSON сериализация: Настройте Jackson (JsonSerialize(using = ToStringSerializer.class) для BigDecimal) чтобы не терять точность при передаче в фронтенд.

Поиск «рваных денег на Яве» (в переносном смысле, потерь точности в Java) заканчивается выбором правильной абстракции. Для 2024–2026 годов оптимальным стеком является:

• Core/Highload: long (минорные единицы) + ручное округление.
• Enterprise/Business Logic: JSR-354 (Moneta) — стандарт, безопасность типов, поддержка валют.
• Legacy/Simple: BigDecimal с жесткими конвенциями (String ctor, MathContext).

Помните: Экономия на типе данных сегодня — это гарантированные потери на сверке завтра. Храните деньги целыми.