Использование 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 г.): о пяти классах параллельных коллекций, которые модифицируют стандартные классы коллекций для нужд параллельного программирования.

Источник

Delfin's blog

Tag Archives: Multithreading

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

Введение

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

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

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

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

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

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

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

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

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

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

AtomicReferenceFieldUpdater

Заключение

Ресурсы