О потокобезопасный счетчиках

После посещения javaday 2015 Kharkiv возникла мысль померить скорость работы разных иплементаций потокобезопасного счетчика. Участники забега:

1. AtomicLong jre7
2. AtomicLong jre8
3. Synchronized
4. RentrantLock nonFair
5. LongAdder

По следам javaday2015 Kharkiv

Небольшой экспрес анализ того, что удалось узнать на конференции.
1. Spring. Еще раз подтвердилось, что это musthave фреймворк для любогу разработчика javaEE. При чем важно не только умение пользоваться его плюшками, а и понимание того, как он работает. Есть посыл к тому, чтоб опробовать разные версии конфигурирования.
2. Spring Data REST интересная технология для быстрого старта приложений. Позволяет дергать jpa-репозитории через REST, написав минимум кода.
3. Технология Hypermedia API. Идея в том, чтоб приложение возвращало не только запрашиваемые данные, но и ссылки на методы которые можно применить к этим данным. @see HATEOAS, Hypertext Application Language.
4. Spring REST docs. Идея в том, что на REST сервисы пишут тесты (Spring MockMVC) и на выходе получают актуальную документацию по REST API  с примерами вызова и примерами ответов.
5. Gradle. Никто из докладчиков не конфигурировал проект через maven. Стоит задуматься.
6. Cross Site Request Forgery все еще встречается и нужно об этом помнить.
7. JSF это моветон и нужно разделять ответственность между бекендом и фронтендом.
8. Микросервисы. В этом есть профит, но начинать лучше с монолитного приложения.
9. Apache async http client.
10. Asio Sound System и электрогитара.
11. CAS и неблокирующие алгоритмы. Честность это дорого. CAS давно уже поддерживается в java. Если компьютер поддерживает CAS интрукции, то для изменения Long они будут использованы. При компиляции в байткод циклы, которые есть в реализациях типа incrementAndGet() по разному компилируются JIT-ом в 7й и 8й java. В 8й после компиляции нет никаких циклов, а одна единственная инструкция процессора. И в этом профит. Нужно переходить на 8.
12. 7я java мертва =(

Использование isReachable без root прав

Для определения доступности хоста в java можно использовать InetAddress.isReachable(int timeout). Столкнулся c проблемой, что в Linux этот метод не всегда правильно отрабатывает.
В javadoc есть описание:

"A typical implementation will use ICMP ECHO REQUESTs
if the privilege can be obtained, otherwise it will
try to establish a TCP connection on port 7 (Echo) of the destination host."

Наверное в этом месте уже стоит задуматься о каких правах идет речь. Если покопаться в исходниках jdk, то в классе Inet4AddressImpl.c можно найти такой код:

/*
* Let's try to create a RAW socket to send ICMP packets
* This usually requires "root" privileges, so it's likely to fail.
*/
fd = JVM_Socket(AF_INET, SOCK_RAW, IPPROTO_ICMP);
if (fd != -1) {
/*
* It didn't fail, so we can use ICMP_ECHO requests.
*/
return ping4(env, fd, &him, timeout, netif, ttl);
}
/*
* Can't create a raw socket, so let's try a TCP socket
*/
fd = JVM_Socket(AF_INET, SOCK_STREAM, 0);

Получается, чтобы доступность хоста определялась  с помощью ICMP запроса, приложение должно быть запущено с правами root. В противном случае будет использовать echo реквест по 7 TCP порту. Вот только не всегда можно запускать приложения от рута, да и не серьезное это решение какое-то. Чтоб создать "сырой" сокет не обязательно ж быть рутом. Достаточно разрешить это делать jvm. Делается это довольно просто:

setcap cap_net_raw=ep /usr/lib/jvm/jdk/bin/java