Операторы Inner Join и Outer (left, right, full) Join в SQL (Oracle)

December 15, 2017 by delfin

Ключевое слово join в SQL используется при построении select выражений. Инструкция Join позволяет объединить колонки из нескольких таблиц в одну. Объединение происходит временное и целостность таблиц не нарушается. Существует три типа join-выражений:

inner join;
outer join;
cross join;

В свою очередь, outer join может быть left, right и full (слово outer обычно опускается).

В качестве примера (DBMS Oracle) создадим две простые таблицы и сконструируем для них SQL-выражения с использованием join.

В первой таблице будет хранится ID пользователя и его nick-name, а во второй – ID ресурса, имя ресурса и ID пользователя, который может этот ресурс администрировать.

create table t_users (
t_id number (11, 0),
t_nick varchar(16),
primary key (t_id) )

create table t_resources (
t_id  number(11, 0),
t_name varchar(16),
t_userid number (11, 0),
primary key (t_id) )

create table t_users (

t_id number (11, 0),

t_nick varchar(16),

primary key (t_id) )

create table t_resources (

t_id number(11, 0),

t_name varchar(16),

t_userid number (11, 0),

primary key (t_id) )

Содержимое таблиц пусть будет таким:

T_ID  T_NICK
  1    user1     
  3    user3
  4    user4 

T_ID  T_NAME  T_USERID    
  1    res1     3           
  2    res2     1           
  3    res3     2          
  5    res5     3

T_ID T_NICK

1 user1

3 user3

4 user4

T_ID T_NAME T_USERID

1 res1 3

2 res2 1

3 res3 2

5 res5 3

Конструкция join выглядит так:

... join_type join table_name on condition ...

1	... join_type join table_name on condition ...

Где join_type – тип join-выражения, table_name – имя таблицы, которая присоединяется к результату, condition – условие объединения таблиц.

Кострукция join располагается сразу после select-выражения. Можно использовать несколько таких конструкций подряд для объединения соответствующего кол-ва таблиц. Логичнее всего использовать join в том случае, когда таблица имеет внешний ключ (foreign key).

Inner join необходим для получения только тех строк, для которых существует соответствие записей главной таблицы и присоединяемой. Иными словами условие condition должно выполняться всегда. Пример:

select t_resources.t_name, t_users.t_nick
  from t_resources 
  inner join t_users on t_users.t_id = t_resources.t_userid

select t_resources.t_name, t_users.t_nick

from t_resources

inner join t_users on t_users.t_id = t_resources.t_userid

Результат будет таким:

 T_NAME  T_NICK      
  res2    user1          
  res1    user3    
  res5    user3

T_NAME T_NICK

res2 user1

res1 user3

res5 user3

В случае с left join из главной таблицы будут выбраны все записи, даже если в присоединяемой таблице нет совпадений, то есть условие condition не учитывает присоединяемую (правую) таблицу. Пример:

select t_resources.t_name, t_users.t_nick
  from t_resources 
  left join t_users on t_users.t_id = t_resources.t_userid

select t_resources.t_name, t_users.t_nick

from t_resources

left join t_users on t_users.t_id = t_resources.t_userid

Результат выполнения запроса:

 T_NAME  T_NICK    
  res1    user3     
  res2    user1 
  res3   (null)   
  res5    user3

T_NAME T_NICK

res1 user3

res2 user1

res3 (null)

res5 user3

Результат показывает все ресурсы и их администраторов, вне зависимотсти от того есть они или нет.

Right join отображает все строки удовлетворяющие правой части условия condition, даже если они не имеют соответствия в главной (левой) таблице:

select t_resources.t_name, t_users.t_nick
  from t_resources 
  right join t_users on t_users.t_id = t_resources.t_userid

select t_resources.t_name, t_users.t_nick

from t_resources

right join t_users on t_users.t_id = t_resources.t_userid

А результат будет следующим:

 T_NAME  T_NICK    
  res2    user1     
  res1    user3     
  res5    user3     
  (null)  user4

T_NAME T_NICK

res2 user1

res1 user3

res5 user3

(null) user4

Результирующая таблица показывает ресурсы и их администраторов. Если адмнистратор не задействован, эта запись тоже будет отображена. Такое может случиться, например, если ресурс был удален.

Full outer join (ключевое слово outer можно опустить) необходим для отображения всех возможных комбинаций строк из нескольких таблиц. Иными словами, это объединение результатов left и right join.

select t_resources.t_name, t_users.t_nick
  from t_resources 
  full join t_users on t_users.t_id = t_resources.t_userid

select t_resources.t_name, t_users.t_nick

from t_resources

full join t_users on t_users.t_id = t_resources.t_userid

А результат будет таким:

 T_NAME  T_NICK    
  res1      user3     
  res2      user1     
  res3      (null)   
  res5      user3     
 (null)     user4

T_NAME T_NICK

res1 user3

res2 user1

res3 (null)

res5 user3

(null) user4

Некоторые СУБД не поддерживают такую функциональность (например, MySQL), в таких случаях обычно используют объединение двух запросов:

select t_resources.t_name, t_users.t_nick
  from t_resources
  left join t_users on t_users.t_id = t_resources.t_userid
union
select t_resources.t_name, t_users.t_nick
  from t_resources
  right join t_users on t_users.t_id = t_resources.t_userid

select t_resources.t_name, t_users.t_nick

from t_resources

left join t_users on t_users.t_id = t_resources.t_userid

union

select t_resources.t_name, t_users.t_nick

from t_resources

right join t_users on t_users.t_id = t_resources.t_userid

Наконец, cross join. Этот тип join еще называют декартовым произведением (на английском – cartesian product). Настоятельно рекомендую использовать его с умом, так как время выполнения запроса с увеличением числа таблиц и строк в них растет нелинейно. Вот пример запроса, который аналогичен cross join:

select t_resources.t_name, t_users.t_nick 
  from t_resources, t_users

1 2	select t_resources.t_name, t_users.t_nick from t_resources, t_users

Конструкция Join (в сочетании с другими SQL конструкциями, например, group by) часто встречается при программировании под базы данных. Думаю, эта статья будет вам полезна.

Кстати, для проверки своих знаний в области баз данных (и в частности Oracle) рекомендую воспользоваться этим сайтом онлайн тестирования – Тесты по базам данных.

Источник

Использование ThreadLocal переменных

December 14, 2017 by delfin

Введение

Вы уже наверно знаете, что поля классов в java бывают статические и не статические. Любое поле класса без модификатора static принадлежит объекту данного класса и создается каждый раз когда создается новый экземпляр класса. Статические переменные(помеченные модификатором static) не принадлежат экземпляру класса и существует всегда в единственном экземпляре независимо от того, сколько экземпляров класса было создано. Появившийся в java 1.2 класс java.lang.ThreadLocal по сути предоставляет нам ещё одну область жизни объектов, ThreadLocal предоставляет абстракцию над переменными локальными по отношению к потоку испольнения java.lang.Thread. ThreadLocal переменные отличаются от обычных переменных тем, что у каждого потока свой собственный, индивидуально инициализируемый экземпляр переменной, доступ к которой он получает через методы get() или set().

Я в своей практике встречался с четырьмя основными целями применения ThreadLocal переменных:
1. Упрощение API.
2. Cинтаксический сахар.
3. Кеширование непотокобезопасных(non thread safe) ресурсов.
4. Уменьшение области конкуренции между потоками(lock striping).

Упрощение API с помощью ThreadLocal.

Допустим Вы разрабатываете JEE веб приложение, после прохождения аутентификации на странице логина информация о пользователе запоминается в http сессии, и Вам в любой точке кода может понадобится информация о пользователе от которого пришел http запрос.
Наверняка Вы не захотите всю логику помещать в сервлеты и JSP, Вы выделети в приложение несколько слоев(бизнесс логика, доступ к данным и.т.д.), но после распределния ответсвенности по слоям у Вас может возникнуть проблема с тем, что не в каждой точке кода будет доступ к Http сессии, соответсвенно не везде можно будет узнать от какого пользователя пришел запрос.
Встает вопрос? а как проектировать свой API? Добавлять в каждый метод каждого класса дополнительный параметр представляющий данные пользователе?

До появления ThreadLocal это был единственный выход, с появлением же ThreadLocal мы можем привязать данные о пользователи к потоку обработки http запроса, и достать эту информацию в любом месте программы. Для этого нам понадобится зарегистрировать слушателя в контексте веб приложения который будет срабатывать на любой входящий http запрос:

Итак начнем с класса для реализации потокобезопсного контеста пользователя:

package ru.javatalks;

/**
 * @author Vermut
 *
 */
public class SecurityContextHolder {
	
	private static final ThreadLocal threadLocalScope = new  ThreadLocal<>();
	
	public final static User getLoggedUser() {
		return threadLocalScope.get();
	}
	
	public final static void setLoggedUser(User user) {
		threadLocalScope.set(user);
	}

}

package ru.javatalks;

/**

* @author Vermut

public class SecurityContextHolder {

private static final ThreadLocal threadLocalScope = new ThreadLocal<>();

public final static User getLoggedUser() {

return threadLocalScope.get();

}

public final static void setLoggedUser(User user) {

threadLocalScope.set(user);

}

Как мы знаем сервера приложений могут выполнять тысячи запросов одновременно и на первый взгляд такой код не потоко безопасен. Ведь действительно мы запоминаем текущего пользователя в статической переменной, а статическая переменная одна на весь класс, и вроде бы как паралельные http запросы должны перетирать данные друг друга.
Но вся фишка ThreadLocal заключается в том что имея всего одну ThreadLocal переменную, мы можем иметь различное значение для каждого из потоков, то есть один поток никогда не прочтет, удалит или не перезатрет данные присвоенные другим потоком. Таким образом несмотря на разделяемую статическую переменную код выше потоко-безопасен.Хранилище аутентификацционных данных написано, теперь нужно написать и сконфигурировать в web.xml слушателя входящих HTTP запросов, который бы при поступлении запроса присоеденяя данные о пользователе к потоку обработки а по завершении обработки запроса, очищал бы эту информацию.

package ru.javatalks;

import javax.servlet.ServletRequestEvent;
import javax.servlet.ServletRequestListener;
import javax.servlet.http.HttpServletRequest;
import javax.servlet.http.HttpSession;

/**
 * @author Vermut
 *
 */
public class AuthentificationPropagationListener implements ServletRequestListener {

	@Override
	public void requestInitialized(ServletRequestEvent event) {
		HttpServletRequest request = (HttpServletRequest) event.getServletRequest();
		HttpSession session = request.getSession(false);
		if (session == null) {
			return;
		}
		User user = (User) session.getAttribute("loged_user");
		SecurityContextHolder.setLoggedUser(user);
	}
	
	@Override
	public void requestDestroyed(ServletRequestEvent event) {
		SecurityContextHolder.setLoggedUser(null);
	}

}

package ru.javatalks;

import javax.servlet.ServletRequestEvent;

import javax.servlet.ServletRequestListener;

import javax.servlet.http.HttpServletRequest;

import javax.servlet.http.HttpSession;

/**

* @author Vermut

public class AuthentificationPropagationListener implements ServletRequestListener {

@Override

public void requestInitialized(ServletRequestEvent event) {

HttpServletRequest request = (HttpServletRequest) event.getServletRequest();

HttpSession session = request.getSession(false);

if (session == null) {

return;

}

User user = (User) session.getAttribute("loged_user");

SecurityContextHolder.setLoggedUser(user);

}

@Override

public void requestDestroyed(ServletRequestEvent event) {

SecurityContextHolder.setLoggedUser(null);

}

Дело осталось за малым воспользоваться написаными функционалом из любой точки приложения в которой нет доста к http запросу или сессии:

package ru.javatalks;

/**
 * @author Vermut
 *
 */
public class OrderService {
	
	public void createOrder(Order order) {
		User user = SecurityContextHolder.getLoggedUser();
		checkEligibility(user, order.getSum());
		order.setUserId(user.getId())
		...
	}

}

package ru.javatalks;

/**

* @author Vermut

public class OrderService {

public void createOrder(Order order) {

User user = SecurityContextHolder.getLoggedUser();

checkEligibility(user, order.getSum());

order.setUserId(user.getId())

...

}

Конечно же функционал реализованный выше редко когда придется писать самому, есть множество библиотек связанных с security в которых это уже реализовано, например spring-security, стоит только иметь в виду что все они будут точно также работать посредством ThreadLocal. Построение API вокруг ThreadLocal широко используется в java enterprise edition и используется не только для ассоциирования контекста безопасности с потоком, но и для других вещей как например транзакции, открытые JPA сессии. Так же хочу заметить что использование ThreadLocal в JEE окружении сопряжено с возникновением многих проблемам и без глубокого понимания платформы jee, многопоточности и механизма загрузки классов от использования ThreadLocal в JEE лучше отказаться. Проблемы порождаемые ThreadLocal переменными в JEE окружении описаны в конце статьи.

2. Cинтаксический сахар или программирование на языке.

ThreadLocal можно использовть для добавления синтаксического сахара в язык java и многие библиотеки этим пользуются, например mybatis:

private String selectPersonSql() { 
    BEGIN(); // Clears ThreadLocal variable 
    SELECT("P.ID, P.USERNAME, P.PASSWORD, P.FULL_NAME"); 
    SELECT("P.LAST_NAME, P.CREATED_ON, P.UPDATED_ON"); 
    FROM("PERSON P"); 
    FROM("ACCOUNT A"); 
    INNER_JOIN("DEPARTMENT D on D.ID = P.DEPARTMENT_ID"); 
    INNER_JOIN("COMPANY C on D.COMPANY_ID = C.ID"); 
    WHERE("P.ID = A.ID"); 
    WHERE("P.FIRST_NAME like ?"); 
    OR(); 
    WHERE("P.LAST_NAME like ?"); 
    GROUP_BY("P.ID"); 
    HAVING("P.LAST_NAME like ?"); 
    OR(); 
    HAVING("P.FIRST_NAME like ?"); 
    ORDER_BY("P.ID"); 
    ORDER_BY("P.FULL_NAME"); 
    return SQL(); 
  }

private String selectPersonSql() {

BEGIN(); // Clears ThreadLocal variable

SELECT("P.ID, P.USERNAME, P.PASSWORD, P.FULL_NAME");

SELECT("P.LAST_NAME, P.CREATED_ON, P.UPDATED_ON");

FROM("PERSON P");

FROM("ACCOUNT A");

INNER_JOIN("DEPARTMENT D on D.ID = P.DEPARTMENT_ID");

INNER_JOIN("COMPANY C on D.COMPANY_ID = C.ID");

WHERE("P.ID = A.ID");

WHERE("P.FIRST_NAME like ?");

OR();

WHERE("P.LAST_NAME like ?");

GROUP_BY("P.ID");

HAVING("P.LAST_NAME like ?");

OR();

HAVING("P.FIRST_NAME like ?");

ORDER_BY("P.ID");

ORDER_BY("P.FULL_NAME");

return SQL();

}

Код получился легко читаемым, как видно функции BEGIN, SELECT и.т.д. не вызываются ни на одном объекте, то есть они статические и за счет статического импорта появившегося в java 5, вызов таких функций можно осуществлять без префикса класса. Потоко-безопасность достигается за счет того что каждый поток выполнения имеет собственный экземпляр билдера запросов. Конечно следует ожидать, что c появлением лямбд в java 8, использование ThreadLocal в качестве синтаксического сахара потеряет свою актуальность

Кеширование непотокобезопасных(non thread safe) ресурсов.

Однажды делая код ревью одного класса я обнаружил очень интересный баг многопоточности:

public class DateAdapter extends XmlAdapter<String, Date> {

    private static final DateFormat format = new SimpleDateFormat("dd.MM.yyyy");

    @Override
    public String marshal(Date value) throws Exception {
        return format.format(value);
    }

    @Override
    public Date unmarshal(String value) throws Exception {
        return isNullOrEmpty(value)? null: format.parse(value);  
    }

}

public class DateAdapter extends XmlAdapter<String, Date> {

private static final DateFormat format = new SimpleDateFormat("dd.MM.yyyy");

@Override

public String marshal(Date value) throws Exception {

return format.format(value);

}

@Override

public Date unmarshal(String value) throws Exception {

return isNullOrEmpty(value)? null: format.parse(value);

}

Класс использовался как кастомный адаптер для даты в JAXB. Вроде бы простой маленьки класс и в нём негде ошибится, однако есть одно но, класс java.text.SimpleDateFormat не является потоко безопасным, параллельные потоки должны либо синхронизировать доступ к инстансу объекта данного класса, либо отказаться от разделения одного инстанса SimpleDateFormat.
То есть просто создать один экземпляр формата и запомнить в статической переменной нельзя, иначе мы получим мусор на выходе если форматировать даты паралельно из нескольких потоков. Честно говоря в приложении рассчитаном на входящий поток данных 5 тысяч входящих документов в секунду, ни генерировать мусор создавая каждый раз новый экземпляр формата, ни тем более создавать бутылочное горлышко в виде synchronized блоков мне не хотелось, и поскольку стояло жесткое требование по максимуму отказаться от библиотек не входящих в j2se, то есть нельзя было использовать сторонние реализации форматеров то код выше превратился в следующее:

/**
 *
 * @author Vermut
 *
 */
public final class DateAdapter extends XmlAdapter<String, Date> {

    private static final ThreadLocal THREAD_CACHE = new ThreadLocal ();

    @Override
    public String marshal(Date value) throws Exception {
        return getFormat().format(value);
    }

    @Override
    public Date unmarshal(String value) throws Exception {
        return isNullOrEmpty(value)? null: getFormat().parse(value);
    }

    private static DateFormat getFormat() {
        DateFormat format = THREAD_CACHE.get();
        if (format == null) {
            format = new SimpleDateFormat("dd.MM.yyyy");
            THREAD_CACHE.set(format);
        }
        return format;
    }

}

/**

* @author Vermut

public final class DateAdapter extends XmlAdapter<String, Date> {

private static final ThreadLocal THREAD_CACHE = new ThreadLocal ();

@Override

public String marshal(Date value) throws Exception {

return getFormat().format(value);

}

@Override

public Date unmarshal(String value) throws Exception {

return isNullOrEmpty(value)? null: getFormat().parse(value);

}

private static DateFormat getFormat() {

DateFormat format = THREAD_CACHE.get();

if (format == null) {

format = new SimpleDateFormat("dd.MM.yyyy");

THREAD_CACHE.set(format);

}

return format;

}

Как видно обеспечено кеширование объектов DateFormat без синхронизации. В статье Java Best Practices – DateFormat in a Multithreading Environmentприведены результаты бенчмарков показывающих что такой подход позволяет увеличить производительность парсинга дат до 8 раз по сравнению с созданием каждый раз нового экземпляра формата.

Сужение области конкуренции между потоками(lock striping).

Lock striping техника представления сложного объекта, к которому осуществляется конкуретный доступ в виде отдельных маленьких частей, каждую часть такого объекта можно менять без блокировки целого объекта. Например техника lock striping применена в CuncurrentHashMap – вся коллекция разбита на регионы, и треды при модификации не конкурируют за всю коллекцию целиком, они конкурируют за её отдельные регионы, таким образом острота конкуренции снижается.

Прежде всего для этого параграфа хотелось бы сразу поместить disclaimer и cсылку на эту презентацию
, в презентации авторитетные специалисты в области java оптимизации в квалификации которых не возникает ни каких сомнений, крайне не рекомендуют использовать ThreadLocal для сuncurrent оптимизаций.

Однако пока java8 ещё не зарелизена, а в продакшн энтерпрайз приложений java8 попадет вообще не скоро, то пример использования ThreadLocal я всё же опубликую.

И так представим высоконагруженное приложение с тысячами рабочих потоков. Потоки занимаются тем что обрабатывают пачки входящих документов и нам бы хотелось собирать некоторую статистику о работе приложения, а конкретно количество обработанных документов. Но при этом мы бы хотели чтобы сбор статистики обходился нам бесплатно, и не вносил бы лишних нагрузку в приложение.
Какие сть варианты решения:
Выполнять запрос SELECT COUNT(*) FROM TABLE в базу данных – на таких объемах не очень удачное решение.
Заводить AtomicLong – поможет на небольшом количестве потоков, но не на тысячах.

Итак применим ThreadLocal. Общее количество обработанных сервером документов можно представить как сумму обработанных документов каждым рабочим потоком. То есть к каждому треду можно поставить соответсвии число, и он будет увеличивать это число вообще без конкуренции с каким либо другим потоком, то есть как мы и хотели сбор статистики обходится нам бесплатно.

package ru.javatalks;

import java.util.ArrayList;
import java.util.List;

/**
 * @author Vermut
 *
 */
package ru.javatalks;

import java.util.ArrayList;
import java.util.List;
import java.util.concurrent.locks.ReentrantReadWriteLock;

/**
 * @author Vermut
 *
 */
public final class ThreadLocalAdder {
	
	private final ThreadLocal threadLocalScope = new ThreadLocal<>();
	private final List allThreadSums = new ArrayList<>();
	private final ReentrantReadWriteLock readWriteLock = new ReentrantReadWriteLock();
	
	public void add(long value) {
		SumContainer threadLocalSum = threadLocalScope.get();
		if (threadLocalSum == null) {
			threadLocalSum = new SumContainer();
			threadLocalScope.set(threadLocalSum);
			/*
			 * Самое первое получение локального блокирует подсчет общей суммы,
			 * но это критично только пока приложение не войдет в рабочий ритм, 
                         * в разогнавшемся приложении уже каждый поток хоть раз да проинкрементил свой счетчик.
			 */
			readWriteLock.writeLock().lock();
			try {
				allThreadSums.add(threadLocalSum);
			} finally {
				readWriteLock.writeLock().unlock();
			}
		}
		threadLocalSum.value += value;
	}
	
	public long getSum() {
		long sum = 0L;
		/*
		 * Как видно подсчет суммы медленная операция, так как сумма не хранится в готовом для чтения виде,
		 * что в принципе вписывается в концепцию lock striping, и не является критичным моментом в данном конкретном случае,
		 * так как админы приложения могут и несколько дней не заглядывать в перфоманс монитор.
		 */ 
		readWriteLock.readLock().lock();
		try {
			for (SumContainer threadLocalSum : allThreadSums) {
				sum += threadLocalSum.value;
			}
		} finally {
			readWriteLock.readLock().unlock();
		}
		return sum;
	}
	
	private static class SumContainer {
		/*
		 * Поле специально не volatile и не атомик, потому что абсолютная точность не нужна,
		 * допустимо чтобы запрос на получение статиcтики не увидел последних инкрементов сделанных рабочим потоком.
		 * Таким образом мы добились чего хотели, сбор статистики сделан бесплатным, его стоимость равна чтению из
		 * обычного (несинхронизированного) хешмапа коим по сути является ThreadLocal
		 */
		public long value;
		
	}

}

package ru.javatalks;

import java.util.ArrayList;

import java.util.List;

/**

* @author Vermut

package ru.javatalks;

import java.util.ArrayList;

import java.util.List;

import java.util.concurrent.locks.ReentrantReadWriteLock;

/**

* @author Vermut

public final class ThreadLocalAdder {

private final ThreadLocal threadLocalScope = new ThreadLocal<>();

private final List allThreadSums = new ArrayList<>();

private final ReentrantReadWriteLock readWriteLock = new ReentrantReadWriteLock();

public void add(long value) {

SumContainer threadLocalSum = threadLocalScope.get();

if (threadLocalSum == null) {

threadLocalSum = new SumContainer();

threadLocalScope.set(threadLocalSum);

* Самое первое получение локального блокирует подсчет общей суммы,

* но это критично только пока приложение не войдет в рабочий ритм,

* в разогнавшемся приложении уже каждый поток хоть раз да проинкрементил свой счетчик.

readWriteLock.writeLock().lock();

try {

allThreadSums.add(threadLocalSum);

} finally {

readWriteLock.writeLock().unlock();

}

threadLocalSum.value += value;

}

public long getSum() {

long sum = 0L;

* Как видно подсчет суммы медленная операция, так как сумма не хранится в готовом для чтения виде,

* что в принципе вписывается в концепцию lock striping, и не является критичным моментом в данном конкретном случае,

* так как админы приложения могут и несколько дней не заглядывать в перфоманс монитор.

readWriteLock.readLock().lock();

try {

for (SumContainer threadLocalSum : allThreadSums) {

sum += threadLocalSum.value;

}

} finally {

readWriteLock.readLock().unlock();

}

return sum;

}

private static class SumContainer {

* Поле специально не volatile и не атомик, потому что абсолютная точность не нужна,

* допустимо чтобы запрос на получение статиcтики не увидел последних инкрементов сделанных рабочим потоком.

* Таким образом мы добились чего хотели, сбор статистики сделан бесплатным, его стоимость равна чтению из

* обычного (несинхронизированного) хешмапа коим по сути является ThreadLocal

public long value;

}

Для сокращения кода и упрощения понимания концепции ThreadLocal, из кода удалена обработка ситуаций внезапной смерти потоков. По хорошему нужно обрабатывать ситуацию, когда ThreadLocal собирается сборщиком мусора потому, что поток которому она принадлежит более недостижим из корня, но чтобы не отвлекать внимание читателя в сторону PhantomReference обработка этих ситуаций из кода удалена, а аспекты взаимодействия ThreadLocal и сборки мусора вынесены в отдельный параграф.А вот небольшой тест показывающий применение такого аккомулятора:

package ru.javatalks;

/**
 * @author Vermut
 *
 */
public class ThreadLocalAdderTest {
	
	private static final int OBSERVER_SLEEP_TIMEOUT = 1000;
	private static final long ITERATION_COUNT_PEER_THREAD = 1_000_000_000l;
	private static final int THREAD_COUNT = 10;
	private static final long INCREMENT_COUNT = 10;
	
	
	public static void main(String[] args) throws InterruptedException {
		ThreadLocalAdder threadLocalAdder = new ThreadLocalAdder();
		AdderThread[] threads = new AdderThread[THREAD_COUNT];
		for (int i = 0; i < THREAD_COUNT; i++) { threads[i] = new AdderThread(threadLocalAdder); threads[i].start(); } int aliveThreadCount = THREAD_COUNT; long previousSum = 0l; long sum = threadLocalAdder.getSum(); long sumNotChangedBeetweenIterationCount = 0l; long iterationCount = 0; while (aliveThreadCount > 0) {
			Thread.sleep(OBSERVER_SLEEP_TIMEOUT);
			iterationCount ++;
			aliveThreadCount = 0;
			for (AdderThread thread : threads) {
				if (thread.isAlive()) {
					aliveThreadCount ++;
				}
			}
			sum = threadLocalAdder.getSum();
			if (previousSum == sum) {
				sumNotChangedBeetweenIterationCount++;
			}
			System.out.println(iterationCount + " : " + sum + " : " +  sumNotChangedBeetweenIterationCount);
			previousSum = sum;
		}
		System.out.println(sum == ITERATION_COUNT_PEER_THREAD * THREAD_COUNT * INCREMENT_COUNT);
	}
	
	private static final class AdderThread extends Thread {
		
		private ThreadLocalAdder adder;

		public AdderThread(ThreadLocalAdder adder) {
			this.adder = adder;
		}
		
		@Override
		public void run() {
			for (long i = 0; i < ITERATION_COUNT_PEER_THREAD; i++) {
				adder.add(INCREMENT_COUNT);
			}
		}
	}

}

package ru.javatalks;

/**

* @author Vermut

public class ThreadLocalAdderTest {

private static final int OBSERVER_SLEEP_TIMEOUT = 1000;

private static final long ITERATION_COUNT_PEER_THREAD = 1_000_000_000l;

private static final int THREAD_COUNT = 10;

private static final long INCREMENT_COUNT = 10;

public static void main(String[] args) throws InterruptedException {

ThreadLocalAdder threadLocalAdder = new ThreadLocalAdder();

AdderThread[] threads = new AdderThread[THREAD_COUNT];

for (int i = 0; i < THREAD_COUNT; i++) { threads[i] = new AdderThread(threadLocalAdder); threads[i].start(); } int aliveThreadCount = THREAD_COUNT; long previousSum = 0l; long sum = threadLocalAdder.getSum(); long sumNotChangedBeetweenIterationCount = 0l; long iterationCount = 0; while (aliveThreadCount > 0) {

Thread.sleep(OBSERVER_SLEEP_TIMEOUT);

iterationCount ++;

aliveThreadCount = 0;

for (AdderThread thread : threads) {

if (thread.isAlive()) {

aliveThreadCount ++;

}

sum = threadLocalAdder.getSum();

if (previousSum == sum) {

sumNotChangedBeetweenIterationCount++;

}

System.out.println(iterationCount + " : " + sum + " : " + sumNotChangedBeetweenIterationCount);

previousSum = sum;

}

System.out.println(sum == ITERATION_COUNT_PEER_THREAD * THREAD_COUNT * INCREMENT_COUNT);

}

private static final class AdderThread extends Thread {

private ThreadLocalAdder adder;

public AdderThread(ThreadLocalAdder adder) {

this.adder = adder;

}

@Override

public void run() {

for (long i = 0; i < ITERATION_COUNT_PEER_THREAD; i++) {

adder.add(INCREMENT_COUNT);

}

Пять секретов… многопоточного Java-программирования

December 12, 2017 by delfin

Немногие Java™-разработчики могут позволить себе игнорировать многопоточное программирование и поддерживающие его библиотеки платформы Java, но еще меньше тех, кто располагает временем для глубинного изучения потоков. Вместо этого мы изучаем их спонтанно, добавляя в свой инструментарий новые рекомендации и приемы, когда нуждаемся в них. Это не лучший путь, хотя он и позволяет построить и запустить достойное приложение. Понимание потоковых механизмов компилятора Java и JVM поможет вам написать более эффективный, качественный и быстродействующий код Java.
В этой статье из цикла Пять секретов я расскажу о некоторых тонких аспектах многопоточного программирования с применением синхронизированных методов, volatile-переменных и атомарных классов. В частности, мы обсудим взаимодействие некоторых из этих конструкций с JVM и компилятором Java и влияние различных взаимодействий на производительность Java-приложения.

1. Синхронизированный метод или синхронизированный блок?

Развить навыки по этой теме
Этот материал — часть knowledge path для развития ваших навыков. Смотри Стать Java-программистом
Иногда приходится решать, синхронизировать ли вызов метода целиком или только потокобезопасное подмножество этого метода. В таких ситуациях полезно знать, что когда Java-компилятор преобразует исходный код в байт-код, он по-разному обрабатывает синхронизированные методы и синхронизированные блоки.
Когда JVM выполняет синхронизированный метод, исполняемый поток определяет, что в структуре method_info этого метода установлен флаг ACC_SYNCHRONIZED, а затем автоматически блокирует объект, вызывает метод и разблокирует объект. В случае исключительной ситуации поток автоматически снимает блокировку.
При синхронизации же блока кода метода встроенная в JVM поддержка блокировки объекта и обработки исключений не используется, и эта функциональность должна быть явно прописана в байт-коде. Если вы прочтете байт-код метода с синхронизированным блоком, то увидите более десятка дополнительных операций для управления этой функциональностью. В листинге 1 показаны вызовы для создания синхронизированного метода и синхронизированного блока.
Листинг 1. Два подхода к синхронизации

package com.geekcap;
 
public class SynchronizationExample {
    private int i;
 
    public synchronized int synchronizedMethodGet() {
        return i;
    }
 
    public int synchronizedBlockGet() {
        synchronized( this ) {
            return i;
        }
    }
}

package com.geekcap;

public class SynchronizationExample {

private int i;

public synchronized int synchronizedMethodGet() {

return i;

}

public int synchronizedBlockGet() {

synchronized( this ) {

return i;

}

Метод synchronizedMethodGet() генерирует следующий байт-код:

0:  aload_0
1:  getfield
2:  nop
3:  iconst_m1
4:  ireturn

0: aload_0

1: getfield

2: nop

3: iconst_m1

4: ireturn

А вот байт-код метода synchronizedBlockGet():

0:  aload_0
1:  dup
2:  astore_1
3:  monitorenter
4:  aload_0
5:  getfield
6:  nop
7:  iconst_m1
8:  aload_1
9:  monitorexit
10: ireturn
11: astore_2
12: aload_1
13: monitorexit
14: aload_2
15: athrow

0: aload_0

1: dup

2: astore_1

3: monitorenter

4: aload_0

5: getfield

6: nop

7: iconst_m1

8: aload_1

9: monitorexit

10: ireturn

11: astore_2

12: aload_1

13: monitorexit

14: aload_2

15: athrow

Для создания синхронизированного блока понадобилось 16 строк байт-кода, тогда как для синхронизации метода достаточно пяти.

2. Переменные ThreadLocal

Когда нужно сохранить один экземпляр переменной для всех экземпляров класса, используются переменные-члены статического класса. Когда же нужно сохранить по экземпляру переменной для каждого потока, следует использовать локальные переменные потока. Переменные ThreadLocal отличаются от обычных переменных тем, что в каждом потоке есть свой собственный индивидуально инициализированный экземпляр переменной, к которому он обращается посредством методов get() или set().
Допустим, вы разрабатываете многопоточный трассировщик кода, цель которого ― уникально идентифицировать путь каждого потока в вашем коде. Задача в том, чтобы скоординировать несколько методов из нескольких классов между несколькими потоками. Без ThreadLocal это было бы трудно сделать. Пришлось бы в начале исполнения потока создавать уникальный маркер для его идентификации в трассировщике, а затем передавать этот маркер каждому методу, встречающемуся по пути.
ThreadLocal все упрощает. В начале исполнения поток инициализирует локальную переменную потока, а затем обращается к ней из каждого метода в каждом классе с уверенностью, что переменная содержит сведения о трассировке только для текущего исполняемого потока. После исполнения поток может передать сведения о своем пути объекту управления, отвечающему за хранение всех путей.
Использование ThreadLocal имеет смысл, когда нужно хранить экземпляры переменных для каждого потока.

3. Volatile-переменные

По моей оценке, примерно половине всех Java-разработчиков известно о наличии в языке Java ключевого слова volatile. Из них лишь около 10% знают, что оно означает, и еще меньше ― как его эффективно использовать. Вкратце, определение переменной с ключевым словом volatile означает, что значение этой переменной может изменяться другими потоками. Чтобы как следует понять, что делает ключевое слово volatile, полезно разобраться, как потоки обрабатывают обычные переменные.
В целях повышения производительности спецификация языка Java допускает сохранение в JRE локальной копии переменной для каждого потока, который на нее ссылается. Такие «локальные» копии переменных напоминают кэш и помогают потоку избежать обращения к главной памяти каждый раз, когда требуется получить значение переменной.
Но давайте посмотрим, что происходит в следующем сценарии: запускаются два потока, и один из них считывает переменную A как 5, а второй ― как 10. Если значение переменной А изменилось с 5 на 10, то первый поток не узнает об изменении и будет хранить неправильное значение A. Однако если переменная А помечена как volatile, то когда бы поток не считывал значение A, он будет обращаться к главной копии A и считывать ее текущее значение.
Локальный кэш потока имеет смысл в том случае, если переменные в ваших приложениях не будут изменяться извне. Если это не так, то знать, что делает ключевое слово volatile, очень полезно.

4. Volatile- или синхронизированные переменные?

Если переменная объявлена как volatile, это означает, что она может изменяться разными потоками. Естественно ожидать, что JRE обеспечит ту или иную форму синхронизации таких volatile-переменных. JRE действительно неявно обеспечивает синхронизацию при доступе к volatile-переменным, но с одной очень большой оговоркой: чтение volatile-переменной и запись в volatile-переменную синхронизированы, а неатомарные операции ― нет.
Это означает, что следующий код не является потокобезопасным:

myVolatileVar++;

1	myVolatileVar++;

Предыдущий оператор можно записать и так:

int temp = 0;
synchronize( myVolatileVar ) {
  temp = myVolatileVar;
}
 
temp++;
 
synchronize( myVolatileVar ) {
  myVolatileVar = temp;
}

int temp = 0;

synchronize( myVolatileVar ) {

temp = myVolatileVar;

}

temp++;

synchronize( myVolatileVar ) {

myVolatileVar = temp;

}

Другими словами, если volatile-переменная обновляется таким образом, что ее значение считывается, изменяется, и ей “под капотом” присваивается новое значение, то результатом будет непотокобезопасная операция, выполняемая между двумя синхронными операциями. Остается решить, использовать ли явную синхронизацию или же полагаться на поддержку автоматической синхронизации volatile-переменных в JRE. Наилучший подход зависит от обстоятельств: если новое значение volatile-переменной зависит от ее текущего значения (как при операции инкремента), то нужна явная синхронизация, чтобы эта операция была потокобезопасной.

5. Атомарные корректоры полей

При увеличении или уменьшении значения примитива в многопоточной среде гораздо выгоднее использовать один из новых атомарных классов из пакета java.util.concurrent.atomic, чем писать свой собственный синхронизированный блок кода. Атомарные классы гарантируют выполнение определенных операций, таких как увеличение и уменьшение, обновление или добавление значения, потокобезопасным способом. В перечень атомарных классов входят классы AtomicInteger, AtomicBoolean, AtomicLong, AtomicIntegerArray и т.п.
Проблема использования атомарных классов состоит в том, что все операции класса, включая get, set и семейство операций get-set, оказываются атомарными. Это означает, что операции read и write, которые не изменяют значения атомарной переменной, ― это не просто важные, а синхронизированные операции read-update-write. Если требуется более детальное управление развертыванием синхронизированного кода, то обходной путь заключается в использовании атомарного корректора полей.
Использование атомарных обновлений
Атомарные корректоры полей, такие как AtomicIntegerFieldUpdater, AtomicLongFieldUpdater и AtomicReferenceFieldUpdater, по сути, представляют собой оболочку volatile-поля. Они используются внутри библиотек Java-классов. Эти корректоры не нашли широкого применения в коде приложений, но избегать их нет никаких причин.
В листинге 2 приведен пример класса, использующего атомарные корректоры для изменения названия книги, которую кто-то читает.
Листинг 2. Класс Book

package com.geeckap.atomicexample;
 
public class Book
{
    private String name;
 
    public Book()
    {
    }
 
    public Book( String name )
    {
        this.name = name;
    }
 
    public String getName()
    {
        return name;
    }
 
    public void setName( String name )
    {
        this.name = name;
    }
}

package com.geeckap.atomicexample;

public class Book

{

private String name;

public Book()

{

}

public Book( String name )

{

this.name = name;

}

public String getName()

{

return name;

}

public void setName( String name )

{

this.name = name;

}

Класс Book – это простой объект Java (POJO) с единственным полем: name.
Листинг 3. Класса MyObject

package com.geeckap.atomicexample;
 
import java.util.concurrent.atomic.AtomicReferenceFieldUpdater;
 
/**
 *
 * @author shaines
 */
public class MyObject
{
    private volatile Book whatImReading;
 
    private static final AtomicReferenceFieldUpdater<MyObject,Book> updater =
            AtomicReferenceFieldUpdater.newUpdater( 
                       MyObject.class, Book.class, "whatImReading" );
 
    public Book getWhatImReading()
    {
        return whatImReading;
    }
 
    public void setWhatImReading( Book whatImReading )
    {
        //this.whatImReading = whatImReading;
        updater.compareAndSet( this, this.whatImReading, whatImReading );
    }
}

package com.geeckap.atomicexample;

import java.util.concurrent.atomic.AtomicReferenceFieldUpdater;

/**

* @author shaines

public class MyObject

{

private volatile Book whatImReading;

private static final AtomicReferenceFieldUpdater<MyObject,Book> updater =

AtomicReferenceFieldUpdater.newUpdater(

MyObject.class, Book.class, "whatImReading" );

public Book getWhatImReading()

{

return whatImReading;

}

public void setWhatImReading( Book whatImReading )

{

//this.whatImReading = whatImReading;

updater.compareAndSet( this, this.whatImReading, whatImReading );

}

Класс MyObject в листинге 3 предоставляет свое свойство whatAmIReading обычным образом, с помощью методов get и set, но метод set делает нечто особенное. Вместо того чтобы просто присвоить свою внутреннюю ссылку Book указанному объекту Book (что достигается с помощью кода, закомментированного в листинге 3), он использует AtomicReferenceFieldUpdater.

AtomicReferenceFieldUpdater

В Javadoc класс AtomicReferenceFieldUpdater определяется следующим образом:
Основанная на отражении (reflection-based) утилита, которая обеспечивает атомарное обновление указанных опорных volatile-полей указанных классов. Этот класс предназначен для использования в атомарных структурах данных, где несколько опорных полей одного и того же узла независимо подлежат атомарному обновлению.
В листинге 3 класс AtomicReferenceFieldUpdater создается с помощью вызова его статического метода newUpdater, принимающего три параметра:
класс объекта, содержащий поле (в данном случае, MyObject);
класс объекта, подлежащий атомарному обновлению (в данном случае, Book);
имя поля, подлежащего атомарному обновлению.
Реальная выгода здесь заключается в том, что метод getWhatImReading выполняется без всякой синхронизации, в то время как setWhatImReading выполняется как атомарная операция.
В листинге 4 показано, как использовать метод setWhatImReading() с гарантией правильного изменения значения.
Листинг 4. Пример атомарного обновления

package com.geeckap.atomicexample;
 
import org.junit.Assert;
import org.junit.Before;
import org.junit.Test;
 
public class AtomicExampleTest
{
    private MyObject obj;
 
    @Before
    public void setUp()
    {
        obj = new MyObject();
        obj.setWhatImReading( new Book( "Java 2 From Scratch" ) );
    }
 
    @Test
    public void testUpdate()
    {
        obj.setWhatImReading( new Book( 
                "Pro Java EE 5 Performance Management and Optimization" ) );
        Assert.assertEquals( "Incorrect book name", 
                "Pro Java EE 5 Performance Management and Optimization", 
                obj.getWhatImReading().getName() );
    }
 
}

package com.geeckap.atomicexample;

import org.junit.Assert;

import org.junit.Before;

import org.junit.Test;

public class AtomicExampleTest

{

private MyObject obj;

@Before

public void setUp()

{

obj = new MyObject();

obj.setWhatImReading( new Book( "Java 2 From Scratch" ) );

}

@Test

public void testUpdate()

{

obj.setWhatImReading( new Book(

"Pro Java EE 5 Performance Management and Optimization" ) );

Assert.assertEquals( "Incorrect book name",

"Pro Java EE 5 Performance Management and Optimization",

obj.getWhatImReading().getName() );

}

Подробнее об атомарных классах см. в разделе Ресурсы.

Заключение

Многопоточное программирование всегда сложно, но по мере развития платформы Java некоторые из его задач упрощаются. В этой статье я раскрыл пять секретов создания многопоточных приложений на платформе Java, включая разницу между методами синхронизации и синхронизированными блоками кода, важность использования переменных ThreadLocal, сохраняющихся в каждом потоке, малоизвестное ключевое слово volatile (и опасность опоры на volatile при решении задач синхронизации) и краткий экскурс в тонкости атомарных классов. Подробнее см. в разделе Ресурсы.

Ресурсы

Оригинал статьи: 5 things you didn’t know about … multithreaded Java programming.
Пять секретов…: цикл статей, содержащих полезные советы по Java-программированию.
Java Concurrency in Practice (Brian Goetz, et. al. Addison-Wesley, 2006): удивительная способность Брайана объяснять сложные концепции простым языком делает эту книгу необходимой в библиотеке любого Java-программиста.
Code Tracing (Steven Haines, InformIT, август 2010 г.): подробнее о трассировке кода с помощью переменных ThreadLocal.
Java bytecode: Understanding bytecode makes you a better programmer(Peter Haggar, developerWorks, июль 2001 г.): введение в малоизвестные области байткода, включая приведенный выше пример, иллюстрирующий разницу между синхронизированными методами и синхронизированными блоками.
Java theory and practice: Going atomic (Brian Goetz, developerWorks, ноябрь 2004 г.): о том, как атомарные классы позволяют разрабатывать высокомасштабируемые неблокирующие алгоритмы на языке Java.
Java theory and practice: Concurrency made simple (sort of) (Brian Goetz, developerWorks, ноябрь 2002 г.): экскурс в пакет java.util.concurrent.
5 things you didn’t know about … java.util.concurrent, Part 1 (Ted Neward, developerWorks, май 2010 г.): о пяти классах параллельных коллекций, которые модифицируют стандартные классы коллекций для нужд параллельного программирования.

Источник

Как работает ConcurrentHashMap

December 11, 2017 by delfin

В октябре на хабре появилась замечательная статья про работу HashMap. Продолжая данную тему, я собираюсь рассказать о реализации java.util.concurrent.ConcurrentHashMap.
Итак, как же появился ConcurrentHashMap, какие у него есть преимущества и как он был реализован.

Предпосылки к созданию ConcurrentHashMap

До появления в JDK 1.5 реализации ConcurrentHashMap, существовало несколько способов описания хэш-таблиц.
Первоначально в JDK 1.0 был клас Hashtable. Hashtable — потокобезопасная и легкая в использовании реализация хэш-таблицы. Проблема HashTable заключалась, в первую очередь, в том, что при доступе к элементам таблицы производилась её полная блокировка. Все методы Hashtable были синхронизированными. Это являлось серьёзным ограничением для многопоточной среды, поскольку плата за блокировку всей таблицы была очень большой.
В JDK 1.2 на помощь Hashtable пришёл HashMap и его потокобезопасное представление — Collections.synchronizedMap. Причин для такого разделения было несколько:

Не каждый программист и не каждое решение нуждались в использовании потокобезопасной хэш-таблицы
Программисту необходимо было дать выбор, какой вариант ему удобно использовать

Таким образом, c JDK 1.2 список вариантов реализации хэш-карт в Java пополнился ещё двумя способами. Однако эти способы не избавили разработчиков от появления в их коде race conditions, которые могли привести к появлению ConcurrentModificationException. В данной статье подробнее рассказано о возможных причинах их появления в коде.
И вот, в JDK 1.5 наконец появляется более производительный и масштабируемый вариант.

ConcurrentHashMap

К моменту появления ConcurrentHashMap Java-разработчики нуждались в следующей реализации хэш-карты:

Потокобезопасность
Отсутствие блокировок всей таблицы на время доступа к ней
Желательно, чтобы отсутствовали блокировки таблицы при выполнении операции чтения

Doug Lea представляет вариант реализации такой структуры данных, которая включается в JDK 1.5.
Какие же основные идеи реализации ConcurrentHashMap?

1. Элементы карты

В отличие от элементов HashMap, Entry в ConcurrentHashMap объявлены как volatile. Это важная особенность, также связанная с изменениями в JMM. Ответ Doug Lea о необходимости использования volatile и возможных race condition можно прочитать здесь.

static final class HashEntry<K, V> {
    final K key;
    final int hash;
    volatile V value;
    final HashEntry<K, V> next;

    HashEntry(K key, int hash, HashEntry<K, V> next, V value) {
        this .key = key;
        this .hash = hash;
        this .next = next;
        this .value = value;
     }

    @SuppressWarnings("unchecked")
    static final <K, V> HashEntry<K, V>[] newArray(int i) {
        return new HashEntry[i];
    }
}

static final class HashEntry<K, V> {

final K key;

final int hash;

volatile V value;

final HashEntry<K, V> next;

HashEntry(K key, int hash, HashEntry<K, V> next, V value) {

this .key = key;

this .hash = hash;

this .next = next;

this .value = value;

}

@SuppressWarnings("unchecked")

static final <K, V> HashEntry<K, V>[] newArray(int i) {

return new HashEntry[i];

}

2. Хэш-функция

В ConcurrentHashMap также используется улучшенная функция хэширования.
Напомню, какой она была в HashMap из JDK 1.2:

static int hash(int h) {
    h ^= (h >>> 20) ^ (h >>> 12);
    return h ^ (h >>> 7) ^ (h >>> 4);
}

static int hash(int h) {

h ^= (h >>> 20) ^ (h >>> 12);

return h ^ (h >>> 7) ^ (h >>> 4);

}

Версия из ConcurrentHashMap JDK 1.5:

private static int hash(int h) {
    h += (h << 15) ^ 0xffffcd7d;
    h ^= (h >>> 10);
    h += (h << 3);
    h ^= (h >>> 6);
    h += (h << 2) + (h << 14);
    return h ^ (h >>> 16);
}

private static int hash(int h) {

h += (h << 15) ^ 0xffffcd7d;

h ^= (h >>> 10);

h += (h << 3);

h ^= (h >>> 6);

h += (h << 2) + (h << 14);

return h ^ (h >>> 16);

}

В чём необходимость усложнения хэш-функции? Таблицы в хэш-карте имеют длину, определяемую степенью двойки. Для хэш-кодов, двоичные представления которых не различаются в младшей и старшей позиции, мы будем иметь коллизии. Усложнение хэш-функции как раз решает данную проблему, уменьшая вероятность коллизий в карте.

3. Сегменты

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

    final Segment<K, V>[] segments;
    transient Set<K> keySet;
    transient Set<Map.Entry<K, V>> entrySet;
    transient Collection<V> values;

final Segment<K, V>[] segments;

transient Set<K> keySet;

transient Set<Map.Entry<K, V>> entrySet;

transient Collection<V> values;

Рассмотрим, что же представляет из себя класс сегмента:

static final class Segment<K, V> extends ReentrantLock implements 
                    Serializable {
    private static final long serialVersionUID = 2249069246763182397L;
    transient volatile int count;
    transient int modCount;
    transient int threshold;
    transient volatile HashEntry<K, V>[] table;

     final float loadFactor;

    Segment(int initialCapacity, float lf) {
         loadFactor = lf;
         setTable(HashEntry.<K, V> newArray(initialCapacity));
     }

    ...
}

static final class Segment<K, V> extends ReentrantLock implements

Serializable {

private static final long serialVersionUID = 2249069246763182397L;

transient volatile int count;

transient int modCount;

transient int threshold;

transient volatile HashEntry<K, V>[] table;

final float loadFactor;

Segment(int initialCapacity, float lf) {

loadFactor = lf;

setTable(HashEntry.<K, V> newArray(initialCapacity));

}

...

}

Учитывая псевдослучайное распределение хэшей ключей внутри таблицы, можно понять, что увеличение количества сегментов будет способствовать тому, что операции модификации будут затрагивать различные сегменты, что уменьшит вероятность блокировок во время выполнения.

4. ConcurrencyLevel

Данный параметр влияет на использование картой памяти и количество сегментов в карте.
Посмотрим на создание карты и на то, как влияет заданный в качестве парамента конструктора concurrencyLevel:

public ConcurrentHashMap(int initialCapacity, float loadFactor, int concurrencyLevel) {
     if (!(loadFactor > 0) || initialCapacity < 0
          || concurrencyLevel <= 0)
     throw new IllegalArgumentException();

     if (concurrencyLevel > MAX_SEGMENTS)
     concurrencyLevel = MAX_SEGMENTS;

     // Find power-of-two sizes best matching arguments
     int sshift = 0;
     int ssize = 1;
     while (ssize < concurrencyLevel) {
          ++sshift;
          ssize <<= 1;
     }
     segmentShift = 32 - sshift;
     segmentMask = ssize - 1;
     this .segments = Segment.newArray(ssize);

     if (initialCapacity > MAXIMUM_CAPACITY)
          initialCapacity = MAXIMUM_CAPACITY;
     int c = initialCapacity / ssize;
     if (c * ssize < initialCapacity)
          ++c;
     int cap = 1;
     while (cap < c)
          cap <<= 1;

     for (int i = 0; i < this .segments.length; ++i)
          this .segments[i] = new Segment<K, V>(cap, loadFactor);
}

public ConcurrentHashMap(int initialCapacity, float loadFactor, int concurrencyLevel) {

if (!(loadFactor > 0) || initialCapacity < 0

|| concurrencyLevel <= 0)

throw new IllegalArgumentException();

if (concurrencyLevel > MAX_SEGMENTS)

concurrencyLevel = MAX_SEGMENTS;

// Find power-of-two sizes best matching arguments

int sshift = 0;

int ssize = 1;

while (ssize < concurrencyLevel) {

++sshift;

ssize <<= 1;

}

segmentShift = 32 - sshift;

segmentMask = ssize - 1;

this .segments = Segment.newArray(ssize);

if (initialCapacity > MAXIMUM_CAPACITY)

initialCapacity = MAXIMUM_CAPACITY;

int c = initialCapacity / ssize;

if (c * ssize < initialCapacity)

++c;

int cap = 1;

while (cap < c)

cap <<= 1;

for (int i = 0; i < this .segments.length; ++i)

this .segments[i] = new Segment<K, V>(cap, loadFactor);

}

Количество сегментов будет выбрано как ближайшая степень двойки, большая чем concurrencyLevel. Ёмкость каждого сегмента, соответственно, будет определяться как отношение округлённого до ближайшей большей степени двойки значения ёмкости карты по умолчанию, к полученному количеству сегментов.
Очень важно понимать две следующие вещи. Занижение concurrencyLevel ведёт к тому, что более вероятны блокировки потоками сегментов карты при записи. Завышение показателя ведёт к неэффективному использованию памяти.

Как же выбрать concurrencyLevel?

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

Оценки масштабируемости

На javamex можно найти статью о сравнении масштабируемости synchronizedMap и ConcurrentHashMap:

Как видно из графика, между 5 и 10 миллионами операций доступа к карте заметно серьёзное расхождение, что обуславливает эффективность применения ConcurrentHashMap в случае с высоким количеством хранимых данных и операций доступа к ним.

Итого

Итак, основные преимущества и особенности реализации ConcurrentHashMap:

Карта имеет схожий с hashmap интерфейс взаимодействия
Операции чтения не требуют блокировок и выполняются параллельно
Операции записи зачастую также могут выполняться параллельно без блокировок
При создании указывается требуемый concurrencyLevel, определяемый по статистике чтения и записи
Элементы карты имеют значение value, объявленное как volatile

В заключение хотелось бы сказать, что ConcurrentHashMap должен применяться грамотно, с предварительной оценкой соотношения чтения и записи в карту. Также по-прежнему имеет смысл использовать HashMap в программах, где нет множественного доступа от нескольких потоков к хранимой карте.
Спасибо за ваше внимание!

Полезные ресурсы по параллельным коллекциям в Java и, в частности, по работе ConcurrentHashMap:

Источник

Delfin's blog

Monthly Archives: December 2017

Операторы Inner Join и Outer (left, right, full) Join в SQL (Oracle)

Использование ThreadLocal переменных

Введение

Упрощение API с помощью ThreadLocal.

2. Cинтаксический сахар или программирование на языке.

Кеширование непотокобезопасных(non thread safe) ресурсов.

Сужение области конкуренции между потоками(lock striping).

Пять секретов… многопоточного Java-программирования

1. Синхронизированный метод или синхронизированный блок?

2. Переменные ThreadLocal

3. Volatile-переменные

4. Volatile- или синхронизированные переменные?

5. Атомарные корректоры полей

AtomicReferenceFieldUpdater

Заключение

Ресурсы

Как работает ConcurrentHashMap

Предпосылки к созданию ConcurrentHashMap

ConcurrentHashMap

1. Элементы карты

2. Хэш-функция

3. Сегменты

4. ConcurrencyLevel

Как же выбрать concurrencyLevel?

Оценки масштабируемости

Итого