Два года подряд я участвовал в проекте стресс-тестирования компании Double Eleven по продвижению, столкнулся со многими проблемами и сильно вырос, поэтому подведу итоги большого стресс-теста по продвижению здесь. И запишите некоторые распространенные проблемы с производительностью приложений Java, которые возникли во время стресс-теста.

1. Почему стресс-тест

1. Выявление узких мест в производительности приложений
2. Исследуйте тесты производительности для приложений
3. Предоставьте ссылку для расширения большой машины продвижения

2. Как стрессовать

На какие показатели ориентироваться

Пропускная способность TPS (отвеченных запросов в секунду)

Время отклика RT (в целом фокусируется на время отклика 90% запросов, наш большой стандарт продвижения, как правило, в течение 1 секунд)

Уровень ошибок (в зависимости от приемлемости бизнеса, наш стандарт большого продвижения не более 2%)

Инструмент измерения давления

Есть много инструментов, которые можно использовать для измерения давления, такие как ab, jmeter, wrk и т. д. Здесь мы в основном представляем ab и jmeter.

1. ab

ab — это инструмент командной строки, который очень прост в использовании,

# -c表示并发数，-n表示请求总数，其他一些参数可以查询手册/相关资料
ab -c 10 -n 200 https://www.baidu.com/

После выполнения команды будет получен отчет о результатах стресс-теста, в котором количество ложных запросов, TPS и RT отмечены на рисунке ниже

2. jmeter

jmeter поддерживает как графический интерфейс, так и режим командной строки,

Графически

Во-первых, добавьте «группу потоков» в «План тестирования», в которой можно задать такие параметры, как количество параллелизма и продолжительность стресс-теста.

Далее необходимо добавить «Сэмплер HTTP-запроса» в «Группу потоков», который будет задавать параметры HTTP-запроса.

Наконец, добавьте компоненты мониторинга для просмотра результатов.Я лично использую «Просмотр дерева результатов», «Сводный отчет» и «График кривой TPS» (необходимо установить).

Сосредоточьтесь на «агрегированном отчете» (обязательно очищайте данные перед каждым стресс-тестом [значок «шестеренка + 2 метлы» выше], иначе данные перед раундом будут перемешаны)

Вышеизложенное является лишь кратким введением.На самом деле, jmeter также поддерживает множество сложных сценариев стресс-тестирования: стресс-тестирование jdbc, стресс-тестирование dubbo, стресс-тестирование динамических параметров, пользовательские утверждения ответа... Их можно найти в Интернете самостоятельно.

режим командной строки

命令行方式主要可以用来做一些自动化压测的任务。 Он используется следующим образом:

jmeter -n -t [jmx脚本] -l [压测请求结果文件] -e -o [压测报告文件夹(会生成一堆网页文件)]

Сценарий Jmx, который можно запустить с помощью графического интерфейса jmeter, все настроено, а затем сохранить его, сгенерирует соответствующий сценарий jmx.

3. Сравнение AB и JMeter

	ab	jmeter
Сложность эксплуатации	Простой	сложный
Командная строка	Поддержка, простота в эксплуатации	Поддержка, операция немного сложнее
список результатов запроса	невозможно отобразить	Есть подробный список запросов
Динамические параметры	не поддерживается	служба поддержки
Поддержка сложных сцен	крайне ограниченный	Богатый

В принципе, для некоторых простых запросов с фиксированными параметрами и самотестирования использование ab будет очень удобно. В целом применимость jmeter будет шире.

3. Как сформулировать цель большого рекламного прессинга

Выбор интерфейса измерения давления

Как правило, нет необходимости проводить стресс-тестирование всех интерфейсов компании. Интерфейсы стресс-тестирования в основном включают в себя интерфейсы основных каналов, интерфейсы с интенсивным доступом и недавно запущенные активные интерфейсы. В основном есть два способа получить его:

1. Захват основного бизнеса
2. Проконсультируйтесь с руководителями бизнес-направлений

Настройка количества одновременных опрессовок

В приведенных выше двух инструментах стресс-тестирования мы видели, что параметром является количество параллелизма.Этот параметр обычно необходимо рассчитывать на основе объема бизнеса компании.Вы можете найти некоторую информацию в Интернете. Однако, чтобы упростить процесс стресс-тестирования, продвижение нашей компании реализовано с использованием стандарта 200 параллельных интерфейсов чтения и 100 параллельных интерфейсов записи.

На самом деле моя настройка числа параллелизма довольно расплывчата, поэтому вышеприведенное описание только для справки.

Настройки TPS

Как правило, окончательная цель TPS формулируется в соответствии с целью продаж большой акции, qps каждого интерфейса и пропорционально объему трафика каждого интерфейса.Не забудьте умножить фактор риска в конце. Конкретный алгоритм можно разработать самостоятельно, а общая идея такова.

В-четвертых, на какие показатели обратить внимание

Показатели инструмента измерения напряжения были упомянуты выше, в основном с акцентом на TPS, RT и частоту ошибок.

Так на какие еще показатели нужно обращать внимание? На самом деле это определяется бизнесом компании.Например, наша компания в основном использует java-приложения, mysql в качестве базы данных и Redis в качестве промежуточного программного обеспечения для кэширования.Тогда данные о производительности, на которые мы в основном ориентируемся, следующие:

Объект мониторинга	Представление
Сервер приложений (сервер приложений, где сервис-ориентированные приложения включают нисходящие каналы)	ЦП, пропускная способность сети, дисковый ввод-вывод, сборщик мусора
база данных	ЦП, пропускная способность сети, медленный SQL
REDIS	пропускная способность сети

Каждый объект мониторинга имеет свои особенности, поэтому следует формулировать свои показатели мониторинга в соответствии с реальной ситуацией.

5. Как устранять проблемы

Поскольку компания в основном использует Java8, в этой статье в основном анализируются приложения Java8.

Зачем искать узкие места

Например, если вам говорят, что интерфейс находится под небольшой нагрузкой, процессор сервера будет заполнен, что приведет к невозможности поднять TPS, в нем много сложной логики и много удаленных вызовов ( запрос к базе данных, запрос к кешу, вызов dubbo. Подождите).

Вы можете быть хорошо знакомы с бизнесом и начать вносить радикальные изменения в код, увеличивать кэш, понижать уровень обслуживания и т. д. Возможно, ожидания очень хорошие, но на самом деле существует большая вероятность того, что все, что вы делаете, окажет лишь незначительное влияние на ТПС. Тогда вы можете найти проблему, только постоянно пытаясь удалить код, что, очевидно, может привести только к нескольким результатам: 1. Неэффективность 2. Код испорчен 3. Он невоспроизводим 4. Это приведет к ущербу для бизнеса Малый или большое влияние, самое главное, что я понятия не имею, когда вношу изменения, и я до сих пор понятия не имею после внесения изменений.

Несколько вопросов (пожалуйста, ответьте в соответствии с вашими собственными фактическими знаниями)

1. Как вы думаете, достижение процессором 100% — это хорошо или плохо?
2. Какой код вы считаете ресурсоемким? Как вы думаете, много логики суждений дорого обходится ЦП?
3. На какие показатели, по вашему мнению, большое влияние оказывает большой объем сетевой передачи данных?
4. Как вы думаете, сколько необходимо для мониторинга серверной памяти для Java-приложений?

Как решить проблемы с производительностью

Итак, вопрос в том, как нам решить проблему? (Ниже приведены некоторые личные впечатления, может быть много упущений, или могут быть некоторые ошибки, если да, пожалуйста, укажите вовремя)

Для устранения проблемы, в первую очередь, нам нужно иметь какие-то точки прорыва и направления для исследования. (Нет гарантии, что можно найти 100% соответствующих проблем, но эффективность поиска проблем с производительностью значительно повышается)

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

1. Проблема с медленным SQL в базе данных

Эта проблема является лучшим видом проблемы для устранения неполадок.Для этого нужно только целенаправленно анализировать и оптимизировать медленный SQL.Я не буду объяснять это здесь.

2. Слишком большая пропускная способность сети

Итак, возникает вопрос, что здесь означает пропускная способность сети? Скажем иначе, допустим верхний предел пропускной способности базы данных 1Gbps, а на самом деле сетевая пропускная способность базы данных занята 800Mbps из-за стресс-теста, значит ли это, что данный интерфейс является проблемным интерфейсом?

Рассмотрим следующую ситуацию: предполагается, что в процессе нагрузочного тестирования показатель TPS этого интерфейса достигает 80 000, что значительно превышает фактическое целевое значение TPS интерфейса. Вполне разумно, чтобы интерфейс занимал пропускную способность базы данных 800 Мбит/с.

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

Как устранить неполадки с чрезмерной пропускной способностью сети

Угадайте что, нетрудно представить, это просто захват пакетов. Способ, которым я обычно перехватываю пакеты, заключается в том, чтобы перехватывать пакеты через tcpdump, а затем использовать wireshark для разбора содержимого захваченных пакетов (если есть более простой способ, вы можете оставить сообщение). Давайте поговорим о том, как tcpdump+wireshark перехватывает пакеты.

Чтобы избежать смешивания большого количества данных, я обычно предпочитаю собирать данные одного запроса, а не собирать пакеты в стресс-тесте. Ниже приведено краткое введение в то, как tcpdump и wireshark перехватывают пакеты.

1. Выполнить команду на сервереsudo tcpdump -w xxx.pcap
2. Затем попросите суставы
3. Ctrl+C останавливает tcpdump
4. Скопируйте xxx.pcap локально и откройте его с помощью wireshark
5. Как показано ниже, найдите запрос> щелкните правой кнопкой мыши «Подписаться»> «TCP Stream».

После открытия потока TCP, настроив «Поток» в правом нижнем углу, мы можем увидеть сетевые данные приложения в процессе запроса (включая данные запроса Http, данные запроса Mysql, данные запроса Redis...), следующие рисунок является примером, вы можете видеть, что количество запросов mysql к этому запросу очень велико, и следующим шагом является проверка того, какие операторы SQL вызывают это.

3. ЦП базы данных слишком высок

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

4. Проблема с дисковым вводом-выводом сервера приложений

В большинстве случаев это вызвано проблемами с журналом.Проблемы с журналом обычно делятся на следующие два случая:

1. Существует проблема с параметрами/средой интерфейса проверки давления, из-за которой интерфейс постоянно выводит исключения.
2. Печатайте много бизнес-журналов

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

5. Проблемы с сборщиком мусора

В нормальных условиях не нужно обращать внимание на YoungGC, а нужно обращать внимание только на FullGC.Если есть только изредка FullGC, это в принципе не большая проблема.Несколько раз в секунду), то нужно проверить соответственно.

Как контролировать Fullgc

Как правило, это можно отслеживать с помощью jstat, команда выглядит следующим образом:

jstat -gccause [PID] 1000

Конкретное значение каждого параметра можно просмотретьman jstatруководство.

На самом деле, используя visualvm для установки подключаемого модуля сборщика мусора и наблюдения за процессом Java, вы можете интуитивно видеть состояние памяти и сборщика мусора приложения Java, но эта операция относительно громоздка.

Как устранить проблемы с ГХ

Во многих случаях (в основном крупные объекты / большое количество объектов кучи вызывают fullgc), вы можете сбросить кучу Java и проанализировать его с помощью инструментов анализа памяти, такими как MAT и JHAT. Процесс выглядит следующим образом:

1. Сначала нужен дамп состояния, выполните на сервере следующую команду:jmap -dump:format=b,file=heap.bin [PID]
2. Затем скопируйте файл кучи на локальный, используйте MAT, чтобы открыть его (необходимо увеличить параметры запуска памяти, он должен быть больше, чем файл кучи), наиболее часто используемые функции MAT — «Подозрения на утечку» и «Гистограмма», первый может вызвать утечку памяти Сомнительный момент, последний представляет собой гистограмму классов в куче

Например

Вот пример кучи реального Java-приложения, которое потерпело крах (добавьте -XX:+HeapDumpOnOutOfMemoryError для автоматического создания дампа кучи при возникновении OOM)

В этой статье кратко рассматриваются «Подозрения на утечку», а что касается гистограммы, вы можете изучить ее самостоятельно.

Этот файл кучи на самом деле относительно прост, потому что есть только одна подозрительная точка, и с ней есть проблема. Нажмите «Подробнее», чтобы увидеть более подробную информацию (ps: не у каждого подозреваемого есть подробности).

В деталях, которые в основном можно ясно видеть, есть оператор SQL, чтобы проверить супер-больше данных, в результате чего память уместилась бы. На самом деле, это заявление, наконец, найдено в журнале базы данных, в общей сложности 200 Вт + запрос данных.

Этот пример относительно просты, на самом деле мы можем столкнуться с более сложными ситуациями, такими как особенно подозреваемые, и даже реальная причина не под сомнением объектом, или FULLGC MetaStce вызвало эти случаи, нам вполне может потребоваться использовать другие средства для решения с этим вопросы.

6. Проблема, заключающаяся в том, что ЦП сервера приложений достигает 100% (следующее относится только к обычным бизнес-приложениям и не учитывает стремление к приложениям с экстремальной производительностью)

Помните предыдущий вопрос - как вы думаете, хорошо или плохо, если процессор работает на 100%?

Тогда я раскрою ответ здесь, Если TPS интерфейса высокий, то, конечно, чем выше процессор нашего сервера, тем лучше, потому что это показывает, что ресурсы используются полностью. Однако, если TPS интерфейса низкий, то ЦП достигает 100%, что означает, что есть проблема, очень вероятно, что есть проблемный код, который занимает много ЦП.

Тогда есть еще вопрос, какой код, по вашему мнению, имеет большие накладные расходы на процессор?

1. Большое количество суждений бизнес-логики - почти никакого влияния (общее время выполнения десятков тысяч операторов if не может превышать 1 мс)
2. Большое количество сетевого трафика - почти никакого эффекта (будут некоторые накладные расходы процессора, но крайне ограниченные, вы можете найти карту, чтобы увидеть генерацию приложения Flame)
3. Блоки поток - почти не эффект (без учета огромного количества переключения потока, то нить заблокирована, не займет процессор)
4. Большое количество копий памяти - почти не влияет (будут некоторые накладные расходы процессора, но они крайне ограничены, вы можете найти приложение для создания графика пламени, чтобы увидеть)

Это не имеет никакого эффекта, так что же именно влияет на процессор? Общие бизнес-сценарии резюмируются следующим образом (если есть какие-либо упущения, оставьте сообщение для добавления)

1. Очень длинные циклы, особенно многоуровневые вложенные циклы
2. Обработка строк, общие операции, которые потребляют ресурсы ЦП, — разбор json, регулярные выражения
3. Форматирование даты, Date.format потребляет много ресурсов процессора
4. Большой объем обработки данных sql, в случае обработки большого объема данных sql, займет много процессорного времени, эта ситуация является наиболее распространенной.
5. Большой объем вывода журнала иногда занимает много ресурсов ЦП, но чаще вызывает блокировку потока.

Как решить проблемы с процессором

Способ, которым я больше практикуюсь в пресс-тесте большой акции, — это комбинация perf + perf-map-agent + FlamaGraph, где perf используется для мониторинга потребления процессора каждой функцией (его можно отслеживать в режиме реального времени или записывать для период времени), perf-map-agent используется для помощи perf в создании файла сопоставления кучи java, а FlamaGraph используется для создания графа пламени.

Установка и использование этого инструмента не будут представлены, вы можете обратиться к следующим двум статьям.

Аккаунт леса.GitHub.IO/2018/03/18/… woo woo Краткое описание.com/afraid/Bea2 не 6 ах 1 ой…

Существует два основных способа использования:

1. Sudo Perf Top [-G], вы можете наблюдать расход CPU в режиме реального времени, операция относительно легкая
2. Генерация карты пламени (должна открываться в браузере), операция довольно громоздкая, но сгенерированная информация более подробная, более удобочитаемая, и есть хороший эффект для тех, кто ее не видит.

Пример графика пламени

Ниже показан график пламени, сгенерированный в процессе оптимизации solr во время стресс-теста.Из графика видно, что YoungGC занимает почти половину ЦП.

лучший пример

Используйте этот пример кода, чтобы продемонстрировать использование perf-top:

import java.text.SimpleDateFormat;
import java.util.Date;

public class Cpu {

    private static final int LIMIT = 100000000;

    public static void main(String[] args) {
        simple();
    }

    private static void simple() {
        int count = 0;
        long startTime = System.currentTimeMillis();
        while (count < LIMIT) {
            Date date = new Date();
            SimpleDateFormat df = new SimpleDateFormat("yyyy-MM-dd HH:mm:ss SSS");
            String sd = df.format(date);
            if (sd.length() == 23) {
                count++;
            }
        }
        System.out.println(System.currentTimeMillis() - startTime);
    }
}

первое использованиеperf-map-agent/bin/create-java-perf-map.sh [PID]Сгенерированный JVM файл карты, затем используйтеsudo perf topВидно, что процессор в основном занят SimpleDateFormat, (много еще чего нельзя показать ниже, на самом деле будет больше)

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

каким-то другим способом

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

1. jvmtop
2. GitHub.com/старая крыса Ли/U…, в этом есть скрипт show-busy-java-threads, попробуйте его, он очень удобен, а затем подумайте о том, чтобы попрактиковаться в реальном устранении неполадок.

7. Проблема блокировки потока

Когда мы не можем найти аппаратное узкое место во всех аспектах системы, часто блокируется поток.Как правило, блокировку потока можно проверить с помощью jstack и arthas.Например, используйте следующий пример кода:

public class Main {

    public static void main(String[] args) {
        for (int i = 0; i < 30; i++) {
            new Thread(() -> {
                while (true) {
                    run();
                }
            }, "myThread-" + i);
        }
    }

    private static void run() {
        Integer x = 1;
        for (int i = 0; i < 100000; i++) {
            x *= i;
        }
        System.out.println(x);
        sleep(10);
    }

    private static void sleep(long millis) {
        try {
            Thread.sleep(millis);
        } catch (InterruptedException e) {
            e.printStackTrace();
        }
    }
}

Посмотреть в jstack

jstack [PID]

Как видно из рисунка, застряло большое количество нитей.Block.sleep()начальство. При нормальных обстоятельствах jstack можно использовать с grep, и обычно состояние, которому уделяется больше внимания, — BLOCKED. jstack относительно менее интуитивно понятен, но он относительно легковесен, и во многих случаях можно легко увидеть некоторые распространенные проблемы с блокировкой потоков.

просмотр от Артаса

Arthas на самом деле является более универсальным инструментом анализа производительности jvm, он также является множеством удобных, но относительно легких, настоятельно рекомендуется.

В этой статье в основном рассказывается о применении Arthas для устранения неполадок, связанных с блокировкой потоков.

1. выполнить Артас, командаjava -jar arthas-boot.jar
2. Выберите целевой процесс Java
3. воплощать в жизньtrace [包名.类名] [方法名] -n [数量] '#cost>[执行时间]'Вы можете просмотреть его.Для получения дополнительных параметров вы можете запросить документацию arthas

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

8. Проблема утечки памяти

Проблемы с утечкой памяти часто сопровождаются даунтаймом, я сталкивался со следующими ситуациями:

Утечка кучи памяти

С этой ситуацией относительно легко справиться.Используйте параметр -XX:+HeapDumpOnOutOfMemoryError для автоматического создания дампа файла кучи, когда приложение не работает, а затем используйте инструменты анализа памяти, такие как MAT, чтобы в большинстве случаев найти причину.

утечка памяти в метапространстве

Это привело к тому, что вызов JVM groovy в некоторых случаях приводил к утечкам памяти. Однако связанные с этим проблемы фактически не исследовались, поэтому я их здесь пропущу.

Есть статья о защите от ветра, на которую вы можете сослаться.FullGC, вызванный GroovyClassLoader

утечка памяти без кучи

Проблема утечки памяти, не связанной с кучей, является очень сложной проблемой для устранения. Как правило, трудно создать дамп файла кучи. Даже если дамп не работает, как правило, трудно определить причину. Я использовал такие инструменты, как tcmalloc и jemalloc для расследования. Я пока не нашел более общих подпрограмм, а они вообще частные случаи. Согласно предыдущему опыту устранения неполадок, утечка памяти, не связанной с кучей, чаще всего возникает в следующих ситуациях (если отсутствует, оставьте сообщение для добавления):

1. В бизнесе синтеза изображений задействовано создание шрифта, подробности см. в предыдущей статье.Анализ утечки памяти за пределами кучи JVM, вызванной однократным запоминанием шрифта
2. При использовании JNI весьма вероятно, что область памяти арены JVM просто превысит лимит машинной памяти/утечка памяти без кучи (см. ветрозащитную статьюУтечка памяти вне кучи, вызванная JNI)
3. Дело GZIPStream не закрыто приведет к утечке некучи (информация из интернета, не реальный опыт)

9. Устранение проблем с точки зрения бизнеса

Перед устранением многих проблем лучше сначала понять соответствующую бизнес-логику, поскольку многие проблемы с производительностью вызваны большим количеством проблемных бизнес-кодов.Во многих случаях лучшие результаты могут быть получены с точки зрения бизнеса и дополнены техническими средствами.

10. Резюме

Вышеупомянутые методы обеспечивают только некоторые стратегии, нет гарантии, что 100% проблем могут быть найдены, и даже 70% проблем не могут быть гарантированы, В большинстве случаев нам нужно гибко использовать различные инструменты для анализа проблем. Подводя итог вышеперечисленным инструментам анализа производительности, их можно примерно классифицировать следующим образом:

тип	инструмент
Универсальный инструмент для анализа	Arthas, VisualVm.
инструмент анализа процессора	производительность, jvmtop
инструмент анализа памяти	jmap, jhat, МАТ
инструмент сетевого анализа	TCPDUMP, Wireshark.
Инструмент анализа ГХ	jstat, файлы журнала gc, visualvm
инструмент анализа стека	ДжейСтэк, Артас
Инструменты низкоуровневого устранения неполадок Linux	strace, perf, dmesg, journalctl

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

Шестая, типичные проблемы с производительностью в тесте давления

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

1. Проблема блокировки журнала Log4j

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

2. Проблема больших значений Redis

Некоторые коды напрямую подключаются к Redis независимо от размера данных.Пока параллелизм немного выше, пропускная способность Redis легко может достичь верхнего предела.

3. Проблема запроса полного поля sql

Когда множество кодов запрашивают mysql, независимо от сценария, будут запрошены все поля таблицы, что приведет к двум результатам:

1. Огромная трата пропускной способности сети, особенно если запрос содержит ненужные большие поля, такие как «описание».
2. Огромное потребление ресурсов процессора

4. sql не индексируется

Это относительно простая проблема, которая обычно генерирует медленный SQL и может даже привести к серьезному потреблению ЦП базы данных.

5. Проблема sql N+1

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

6. Проблема с регулярными выражениями

Регулярные выражения также широко используются в бизнесе, но некоторые неправильные регулярные выражения могут привести к ужасным последствиям, которые будут серьезно потреблять ресурсы процессора.Например, как показано ниже.

public class Regex {

    public static void main(String[] args) {
        String regex = "(\\w+,?)+";
        String val = "abcdefghijklmno,abcdefghijklmno+";
        System.out.println(val.matches(regex));
    }
}

Вот такой, казалось бы, простой код, он будет постоянно поддерживать одноядерный процессор в состоянии 100% и будет выполняться около 15 секунд. По конкретным причинам, пожалуйста, обратитесь к статье о защите от ветра.Ууууу.Как будто top.com/posts/2018-…

7. Проблема с форматом даты

Обширное использование DateFormat приводит к огромным потреблению ресурсов процессора. В целом, пожалуйста, используйте FastDateFormat вместо SimpleDateFormat, и производительность может быть более чем удвоиться. В течение некоторых временных моментов, которые относительно регулярны, и точка узкого места все еще находится в DateFormat, вы можете рассмотреть возможность использования таких решений, как кэширование.

8. Неверный пул потоков с использованием проблем

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

9. Легендарный вопрос

Я только слышал об этом, но я никогда не видел его,

1. Большое количество переключений потоков приводит к высокой нагрузке на ЦП.
2. Проблема взаимоблокировки базы данных
3. Проблема настройки соединения соединения базы данных (произошло несколько раз, но я там нет)
4. ... ...