|
Ох "не бейте" меня, друзья и коллеги. В джава я новичок, поэтому возможно задаю глупые вопросы, но очень хочу разобраться.
Вводная. Есть необходимость написать многопоточное приложение, которое будет работать на Java. Собственно все бы ничего, но углубляясь в тему, а я ведь хочу написать хорошо и правильно, приобрести положительный опыт, и, главное, чтобы приложение не требовало сразу же рефакторинга.
Приложение будет выполнять определенные бизнес-задачи, читателей будет много, писатель один, и писать он будет нечасто относительно количества чтений.
Теперь суть. Книгу Java. Concurrency in practice только просматривал, грешен, целиком не прочел. Видимо стоит. Читал форумы и статьи о много поточности, пришел к выводу, что есть замечательный фреймворк java.util.concurrency, в котором мне, человеку из мира C#, близким показался класс ReentrantReadWriteLock. Тут как-раз предоставляется возможность читать нескольким читателям, пока не пишет писатель. Набросал я маленький проект для проверки производительности, а какая из реализаций синхронизации показывает себя лучше? Запускал на машине с Windows 7, процессор Intel i5 5570. Java 1.8.
Пробовал следующим образом: есть экземпляр класса с геттерами и сеттерами, в которых используется ReentrandReadWriteLock. Второй аналогичный класс использует Synchronized, третий - volatile-переменные.
В цикле из 100 000 повторов провел три следующих тестирования: сперва из экземпляра одного из вышеуказанных классов читал в локальные переменные в потоке. Одновременно работают 50 потоков.
Реализация полей с ReadLock от ReentrantReadWriteLock показала на чтении (и это без писателей!) в среднем 2700 миллисекунд на выполнение каждого потока (все 100000 повторов)
Реализация с Synchronzed блока показала в среднем 850-970 миллисекунд
Реализация с доступом к volatile-полям через геттеры - до 10 миллисекунд (что понятно).
В этом тестовом проекте сделал возможность тестировать только на запись в синхронизируемые поля объекта. Те же 50 потоков, те же 100 000 циклов. Reentrant все так же проигрывает. Volatile-переменные начинают отнимать в среднем 80-100 миллисекунд, реализация с synchronized-блоками до 900 мс, ReentrantReadWriteLock - целых 2700 миллисекунд. По идее это ведь огромная конкуренция за ресурс, если я правильно понимаю, последний должен справляться с нею лучше в силу того, что не опускается до FAT-блокировок. Но Synchronized показал более высокие результаты.
Наконец, тестирование, когда 50% - это чтение, а 50 - запись (случайным образом) - немного снизилось время, но в целом картина по каждой реализации та же.
Теперь вопрос, почему? Если верить многочисленным источникам в интернете - ReentrantReadWriteLock "должен" был оказаться производительнее. Почему его блокировка как только на чтение, так и в других ситуациях отнимает больше всего времени?
Есть у меня подозрение, что мне не хватает матчасти, какого-то базового понимания, как это работает.
Благодарность не будет иметь предела за ссылки на официальные источники или подробные литературные источники о том, как это работает, когда ReentrantReadWriteLock показывает более положительные результаты, ну и вообще, за тыкание носом в очевидные вещи, которых я вероятно не знаю. :-)
P.S.: Прошу прощения за большой объем текста. Если интересно, готов выложить тестовый проект.
|
