Основной принцип программирования гласит: не изобретать велосипед. Но иногда, чтобы понять, что происходит и как использовать инструмент правильно, нам необходимо это делать. Сегодня изобретаем ConcrurrentHashMap.
Сперва нам понадобятся 2 вещи. Начнем с 2х тестов — первый скажет, что у нашей реализации нет data races (на самом деле нам нужно проверить, правилен ли наш тест также путем тестирования заведомо некорректной реализации), второй тест мы будем использовать для тестирования производительности с точки зрения throughput.
Основной принцип программирования гласит: не изобретать велосипед. Но иногда, чтобы понять, что происходит и как использовать инструмент неправильно, нам нужно это сделать. Сегодня изобретаем паттерн многопоточного выполнения задач.
Представим, что у вас которая вызывает большую загрузку процессора:
public class Counter {
public Double count(double a) {
for (int i = 0; i < 1000000; i++) {
a = a + Math.tan(a);
}
return a;
}
}
Ни для кого не секрет, что при наличии сформулированного эвристического правила под названием CAP Теорема в противовес привычной RDBMS-системе класс NoSQL-решений не может обеспечить полную поддержку ACID. Нужно сказать, что для целого ряда задач в этом нет никакой необходимости и поддержка одного из элементов приводит к компромиссу в разрешении остальных, как итог — большое разнообразие существующих решений. В данной статье я бы хотел рассмотреть различные архитектурные подходы к решению задач по частичному обеспечению требований к транзакционной системе.
К примеру, у вас есть уже настроенный и распространённый по всей компании сервис мониторинга Zabbix а ещё вы пользуетесь поисковым движком Sphinx. Он ищет быстро, но встроенных средств для живого мониторинга его производительности в разрезе индекса не имеет. К примеру, поисковых серверов у вас много и вы хотите соотносить потребление ресурсов системы каждым конкретным индексом дабы понимать — как распределять их по серверам — а так же видеть — какая из коллекций начинает отвечать дольше, чем хотелось бы — и понимать, коррелируется ли это с возрастанием пользовательской нагрузки или ещё чем-то.
В данной статье я бы не хотел заострять внимание на принципе работы сборщика мусора — об этом прекрасно и наглядно описано здесь: habrahabr.ru/post/112676. Хочется больше перейти к практическим основам и количественным характеристикам по настройке Garbage Collection в JVM — и попытаться понять насколько это может быть эффективным.
Количественные характеристики оценки эффективности GC
Рассмотрим следующие показатели:
Пропускная способность Мера, определяющая способность приложения работать в пиковой нагрузке не зависимо от пауз во время сборки и размера необходимой памяти
Время отклика Мера GC, определяющая способность приложения справляться с числом остановок и флуктуаций работы GC
Размер используемой памяти Размер памяти, который необходим для эффективной работы GC
Как правило, перечисленные характеристики являются компромиссными и улучшение одной из них ведёт к затратам по остальным. Для большинства приложений важны все три характеристики, но зачастую одна или две имеют большее значение для приложения — это и будет отправной точкой в настройке.
