Производительность переменной ThreadLocal
@ Ответ Стивена Канберга был очень полезным, но, к сожалению, не полным для моей ситуации. Я пытался реализовать как geographyV2, так и Places.AbsoluteLocation (отдельно). Ни один из них не работает полностью так, как мне нужно (распознавая состояния и их двухбуквенные сокращения таким образом, чтобы их можно было запрашивать у сущностей в ответе).
Таким образом, я могу выбрать:
- Создать свой собственный список состояний, используя имя состояния и двухбуквенную аббревиатуру в качестве синонимов, как описано в самом описании списка. Это работает за исключением двухбуквенных сокращений, которые также являются словами, такими как «in», «hi» и «me».
- Использовать встроенную сборку geographyV2, которая не допускает синонимов и вообще не распознает двухбуквенные сокращения, или
- Использовать Places.AbsoluteLocation, которая распознает двухбуквенные сокращения для состояний, не смущает их со словами, но также захватывает все местоположения, включая города, страны и адреса, и не делает различий между ними, поэтому я не могу разобрать, какая сущность является государством в высказывании типа «Я живу в Лейк-Стивенс, округ Снохомиш, Вашингтон».
Решение: если я объединю 1 с 3, я могу запросить объекты, которые имеют оба этих типа. Если LUIS помечает слово «in» как штат (штат Индиана), я могу проверить, не было ли это слово также помечено как AbsoluteLocation. Если нет, то я могу смело отказаться от этой сущности. Это не идеально, но это обходной путь, который решает проблему.
4 ответа
Выполнение неопубликованных сравнительных тестов, ThreadLocal.get берет приблизительно 35 циклов на повторение на моей машине. Не много. В реализации Sun пользовательская линейная карта хеша зондирования в Thread карты ThreadLocal с к значениям. Поскольку к этому только когда-либо получает доступ единственный поток, это может быть очень быстро.
Выделение маленьких объектов берет подобное количество циклов, хотя из-за исчерпания кэша можно получить несколько более низкие числа в жестком цикле.
Конструкция MessageDigest, вероятно, будет относительно дорогой. Это имеет изрядное количество состояния, и конструкция проходит Provider механизм SPI. Можно быть в состоянии оптимизировать, например, клонируясь или обеспечивая Provider.
Просто, потому что это может быть быстрее, чтобы кэшироваться в ThreadLocal, а не создать, не обязательно означает, что производительность системы увеличится. Вам свяжут дополнительные издержки с GC, который замедляет все.
, Если Ваше приложение очень в большой степени не использует MessageDigest, Вы могли бы хотеть рассмотреть использование стандартного ориентированного на многопотоковое исполнение кэша вместо этого.
В 2009 некоторый JVMs реализовал ThreadLocal с помощью несинхронизируемого HashMap в Thread.currentThread () объект. Это сделало его чрезвычайно быстро (хотя совсем не с такой скоростью, как использование регулярного доступа к полю, конечно), а также гарантировав, что объект ThreadLocal был убран, когда Поток умер. Обновив этот ответ в 2016, это кажется большинством (все?) более новые JVMs используют ThreadLocalMap с линейным зондированием. Я не уверен в производительности тех †“, но я не могу предположить, что это значительно хуже, чем более ранняя реализация.
, Конечно, новый Объект () также очень быстр в эти дни, и Сборщики "мусора" также очень хороши в исправлении недолгих объектов.
, Если Вы не уверены, что создание объекта будет дорогим, или необходимо сохранить некоторое состояние на потоке основанием потока, Вы - более обеспеченное движение для более простого, выделяют, когда необходимое решение, и только переключающийся на реализацию ThreadLocal, когда профилировщик говорит Вам, что Вы должны.
@Pete является корректным тестом перед оптимизацией.
я был бы очень удивлен, если построение MessageDigest имеет любые серьезные издержки по сравнению с фактическим использованием его.
использование мисс ThreadLocal может быть источником утечек и повисших ссылок, которые не имеют ясного жизненного цикла, обычно я никогда не использую ThreadLocal без очень четкого плана того, когда конкретный ресурс будет удален.
Создайте его и измерьте его.
кроме того, Вам только нужен один threadlocal при инкапсуляции сообщения, переваривающего поведение в объект. Если Вы нуждаетесь в локальном MessageDigest и локальном байте [1000] для некоторой цели, создаете объект с messageDigest и байтом [] поле и помещаете тот объект в ThreadLocal, а не обоих индивидуально.