1 В избранное 0 Ответвления 0

OSCHINA-MIRROR/yangdechao_admin-guage-notes

В этом репозитории не указан файл с открытой лицензией (LICENSE). При использовании обратитесь к конкретному описанию проекта и его зависимостям в коде.
Клонировать/Скачать
08Spring知识点总结.md 44 КБ
Копировать Редактировать Web IDE Исходные данные Просмотреть построчно История
Отправлено 24.06.2025 02:12 0782333

1. Какие аннотации используются для определения advice в Spring AOP?

  • Предварительное advice (@Before)
  • Последующее advice (@After)
  • Advice после возврата (@AfterReturning)
  • Advice при возникновении исключения (@AfterThrowing)
  • Оборачивающее advice (@Around)

2. Краткое описание некоторых важных концепций в AOP- AspectJ: аспект — это всего лишь концепция, нет конкретного интерфейса или класса, который с ним связан. Это объединение точки соединения, совета и точки среза.

  • Join point: точка соединения — это место в процессе выполнения программы, например вызов метода или обработка исключений. В Spring AOP поддерживаются только методы уровня соединения.
  • Advice: совет — это логика, определенная в аспекте, которая может быть одного из трёх типов: "around", "before" и "after". В большинстве реализаций AOP совет обычно представлен как интерцептор, который может включать несколько интерцепторов, образуя цепочку вокруг точки соединения.
  • Pointcut: точка среза — используется для выбора точек соединения. В AspectJ точка среза определяет, какие точки соединения должны быть выбраны.
  • Introduction: введение — позволяет аспекту объявить, что объект, который был уведомлен, реализует любые дополнительные интерфейсы, которые он не реализовал. Например, можно сделать так, чтобы прокси-объект представлял два целевых класса.
  • Weaving: плетение — это процесс применения точек соединения, точек среза, советов и аспектов к программе. При помощи точки среза совет вставляется в метод, что позволяет совету выполняться при вызове метода.
  • AOP proxy: прокси AOP — это объект, который реализует протокол аспекта в реализации AOP. В Spring AOP есть два типа прокси: динамический прокси JDK и динамический прокси CGLIB.- Целевой объект: это объект, который был уведомлен.## 3. Порядок выполнения AOP в Spring 4 и Spring 5

Сначала вспомним часто используемые аннотации AOP:

  • @Before: предварительное уведомление: выполняется перед вызовом метода
  • @After: последующее уведомление: выполняется после вызова метода
  • @AfterReturning: уведомление после возврата: выполняется перед завершением метода
  • @AfterThrowing: уведомление при исключении: выполняется при возникновении исключения
  • @Around: оборачивающее уведомление: выполняется вокруг вызова метода

Порядок выполнения AOP в Spring 4 при нормальном выполнении и при возникновении исключения

try {
    @Before
    method.invoke(obj, args);
    @AfterReturning
} catch () {
    @AfterThrowing
} finally {
    @After
}
Нормальное выполнение: @Before(предварительное уведомление) => @After(последующее уведомление) => @AfterReturning(уведомление после возврата)
Выполнение при исключении: @Before(предварительное уведомление) => @After(последующее уведомление) => @AfterThrowing(уведомление при исключении)

Если в конфигурации также задействовано обертывающее оповещение (around advice), то выполнение его предварительной обработки происходит до выполнения @Before.

Предварительная обработка обертывающего оповещения также выполняется до @After, @AfterReturning и @AfterThrowing.

Обычный результат:

предварительная обработка обертывающего оповещения
@Before предварительное оповещение
вызов метода invokeMethod()
постобработка обертывающего оповещения
@After постоповещение
@AfterReturning / @AfterThrowing
```**Аномальный результат:**

```java
предварительная обработка обертывающего оповещения
@Before предварительное оповещение
@After постоповещение
@AfterReturning / @AfterThrowing

Порядок выполнения AOP в Spring 5

обычное выполнение: @Before(предварительное оповещение) => @AfterReturning(обычное завершение) => @After(постоповещение)
анномальное выполнение: @Before(предварительное оповещение) => @AfterThrowing(исключение метода) => @After(постоповещение)

Обычное выполнение с учетом обертывающего оповещения:

предварительная обработка обертывающего оповещения
@Before предварительное оповещение
вызов метода invokeMethod()
@AfterReturning / @AfterThrowing
постобработка обертывающего оповещения
@After постоповещение

Аномальное выполнение с учетом обертывающего оповещения:

предварительная обработка обертывающего оповещения
@Before предварительное оповещение
@AfterReturning / @AfterThrowing
@After

Порядок выполнения AOP в Spring 5

обработка успешного выполнения с использованием оборачивающего советника:

```java
предварительная обработка оборачивания
@Before предварительный советник
вызов метода invokeMethod()
@AfterReturning / @AfterThrowing
@After последующий советник
последняя обработка оборачивания

обработка ошибочного выполнения с использованием оборачивающего советника:

предварительная обработка оборачивания
@Before предварительный советник
@AfterReturning / @AfterThrowing
@After

Аномальный результат:

предварительная обработка обертывающего оповещения
@Before предварительное оповещение
@After постоповещение
@AfterReturning / @AfterThrowing

Порядок выполнения AOP в Spring 5

обычное выполнение: @Before(предварительное оповещение) => @AfterReturning(обычное завершение) => @After(постоповещение)
анномальное выполнение: @Before(предварительное оповещение) => @AfterThrowing(исключение метода) => @After(постоповещение)

Обычное выполнение с учетом обертывающего оповещения:

предварительная обработка обертывающего оповещения
@Before предварительное оповещение
вызов метода invokeMethod()
@AfterReturning / @AfterThrowing
постобработка обертывающего оповещения
@After постоповещение

Аномальное выполнение с учетом обертывающего оповещения:

предварительная обработка обертывающего оповещения
@Before предварительное оповещение
@AfterReturning / @AfterThrowing
@After

Порядок выполнения AOP в Spring 5

обработка успешного выполнения с использованием оборачивающего советника:

```java
предварительная обработка оборачивания
@Before предварительный советник
вызов метода invokeMethod()
@AfterReturning / @AfterThrowing
@After последующий советник
последняя обработка оборачивания

обработка ошибочного выполнения с использованием оборачивающего советника:

предварительная обработка оборачивания
@Before предварительный советник
@AfterReturning / @AfterThrowing
@After

Аномальный результат:

предварительная обработка обертывающего оповещения
@Before предварительное оповещение
@After постоповещение
@AfterReturning / @AfterThrowing

Порядок выполнения AOP в Spring 5

обычное выполнение: @Before(предварительное оповещение) => @AfterReturning(обычное завершение) => @After(постоповещение)
анномальное выполнение: @Before(предварительное оповещение) => @AfterThrowing(исключение метода) => @After(постоповещение)

Обычное выполнение с учетом обертывающего оповещения:

предварительная обработка обертывающего оповещения
@Before предварительное оповещение
вызов метода invokeMethod()
@AfterReturning / @AfterThrowing
постобработка обертывающего оповещения
@After постоповещение

Аномальное выполнение с учетом обертывающего оповещения:

предварительная обработка обертывающего оповещения
@Before предварительное оповещение
@AfterReturning / @AfterThrowing
@After

Порядок выполнения AOP в Spring 5

обработка успешного выполнения с использованием оборачивающего советника:

```java
предварительная обработка оборачивания
@Before предварительный советник
вызов метода invokeMethod()
@AfterReturning / @AfterThrowing
@After последующий советник
последняя обработка оборачивания

обработка ошибочного выполнения с использованием оборачивающего советника:

предварительная обработка оборачивания
@Before предварительный советник
@AfterReturning / @AfterThrowing
@After

Аномальный результат:

предварительная обработка обертывающего оповещения
@Before предварительное оповещение
@After постоповещение
@AfterReturning / @AfterThrowing

Порядок выполнения AOP в Spring 5

обычное выполнение: @Before(предварительное оповещение) => @AfterReturning(обычное завершение) => @After(постоповещение)
анномальное выполнение: @Before(предварительное оповещение) => @AfterThrowing(исключение метода) => @After(постоповещение)

Обычное выполнение с учетом обертывающего оповещения:

предварительная обработка обертывающего оповещения
@Before предварительное оповещение
вызов метода invokeMethod()
@AfterReturning / @AfterThrowing
постобработка обертывающего оповещения
@After постоповещение

Аномальное выполнение с учетом обертывающего оповещения:

предварительная обработка обертывающего оповещения
@Before предварительное оповещение
@AfterReturning / @AfterThrowing
@After

Порядок выполнения AOP в Spring 5

обработка успешного выполнения с использованием оборачивающего советника:

```java
предварительная обработка оборачивания
@Before предварительный советник
вызов метода invokeMethod()
@AfterReturning / @AfterThrowing
@After последующий советник
последняя обработка оборачивания

обработка ошибочного выполнения с использованием оборачивающего советника:

предварительная обработка оборачивания
@Before предварительный советник
@AfterReturning / @AfterThrowing
@After

Аномальный результат:

предварительная обработка обертывающего оповещения
@Before предварительное оповещение
@After постоповещение
@AfterReturning / @AfterThrowing

Порядок выполнения AOP в Spring 5

обычное выполнение: @Before(предварительное оповещение) => @AfterReturning(обычное завершение) => @After(постоповещение)
анномальное выполнение: @Before(предварительное оповещение) => @AfterThrowing(исключение метода) => @After(постоповещение)

Обычное выполнение с учетом обертывающего оповещения:

предварительная обработка обертывающего оповещения
@Before предварительное оповещение
вызов метода invokeMethod()
@AfterReturning / @AfterThrowing
постобработка обертывающего оповещения
@After постоповещение

Аномальное выполнение с учетом обертывающего оповещения:

предварительная обработка обертывающего оповещения
@Before предварительное оповещение
@AfterReturning / @AfterThrowing
@After

Порядок выполнения AOP в Spring 5

обработка успешного выполнения с использованием оборачивающего советника:

```java
предварительная обработка оборачивания
@Before предварительный советник
вызов метода invokeMethod()
@AfterReturning / @AfterThrowing
@After последующий советник
последняя обработка оборачивания

обработка ошибочного выполнения с использованием оборачивающего советника:

предварительная обработка оборачивания
@Before предварительный советник
@AfterReturning / @AfterThrowing
@After
```## 3. Циклическая зависимость в Spring

[Циклическая зависимость](https://www.cnblogs.com/chenpt/p/9896618.html)

### 1) Концепция циклической зависимости

Циклическая зависимость -> циклическое использование. --> Это когда два или более бинов взаимно зависят друг от друга, создавая замкнутый цикл.

Пример: A зависит от B, B зависит от C, а C зависит от A. [Обратите внимание: это не циклический вызов функции [это бесконечный цикл, если нет условий для завершения], это взаимная зависимость объектов.]

![](D:\git-my-flink-workspace\guage-guc\images\spring\1644729041(1).jpg)

### 2) **Две формы циклической зависимости в контейнере Spring**

(1) Циклическая зависимость через конструктор
(2) Циклическая зависимость через setter (setter-зависимость).

### 3) **Обработка циклической зависимости в Spring**

**(1) Циклическая зависимость через конструктор (невозможно решить)**Это циклическая зависимость, созданная через конструкторы. Такая зависимость не имеет решения, и она приводит к выбросу исключения (BeanCreationException).

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

**(2) Циклическая зависимость через setter (решаемая)**Это циклическая зависимость, созданная через setter. 
Решение: Контейнер Spring предварительно выдает bean, который был создан через конструктор, но ещё не завершил другие шаги (например, setter-внедрение). Это решение применимо только для singleton scope bean. Через предварительное выведение singleton-фабрики, другие bean могут ссылаться на этот bean.
**(3) Обработка циклической зависимости для prototype scope bean (невозможно решить)**

Для bean с prototype scope контейнер Spring не может завершить внедрение зависимостей, так как контейнер Spring не кэширует bean с prototype scope, поэтому он не может предварительно вывести bean, который ещё создаётся.
```### 4) **Анализ области (scope)**

beanFactory выполняет не только обязанности IoC, но также управляет жизненным циклом объектов.

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

### 5) Какие типы scope предоставляются контейнером Spring?- singleton: В контейнере Spring существует только один экземпляр, все объекты будут использовать этот единственный экземпляр. (Примечание: не путайте с паттерном Singleton)
- prototype: Каждый раз, когда контейнер получает запрос, он создает новый экземпляр объекта.
- request (используется только в веб-приложениях): Для каждого HTTP-запроса создается новый объект request-processor для текущего запроса, и после завершения запроса, жизнь этого объекта заканчивается.
- session (используется только в веб-приложениях): Для каждого отдельного сессионного контекста создается новый экземпляр объекта UserPreference.
- global session (используется только в веб-приложениях): Этот тип scope имеет смысл только при использовании портлетов в веб-приложениях. Он отображает глобальный scope сессии портлета. Если этот тип scope используется в обычном веб-приложении на основе servlet, контейнер будет рассматривать его как обычный scope сессии.## 4. Как определить наличие циклической зависимости?

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

## 5. Как Spring решает проблему циклической зависимости?

**Spring использует тройное кэширование для решения проблемы циклической зависимости**

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

Инициализация singleton-объекта в Spring состоит из трех шагов:

(1) createBeanInstance: Инстанцирование, то есть вызов конструктора объекта для его инстанцирования.

(2) populateBean: Заполнение свойств, этот шаг включает заполнение зависимостей объекта.

(3) initializeBean: Вызов метода init из XML конфигурации Spring.Из вышеописанных шагов инициализации singleton-объекта можно понять, что циклическая зависимость обычно возникает на этапах (1) и (2). То есть на этапах конструкторской циклической зависимости и циклической зависимости полей. Чтобы решить проблему циклических зависимостей, следует обратиться к процессу инициализации. Для синглтона существует всего один объект в течение всего жизненного цикла контейнера Spring, поэтому логично предположить, что этот объект должен храниться в кэше. Чтобы решить проблему циклической зависимости синглтонов, Spring использует три уровня кэширования.Давайте рассмотрим исходный код. Три уровня кэширования включают:

```java
/** Кэш синглтон-объектов: имя бина --> экземпляр бина */
private final Map<String, Object> singletonObjects = new ConcurrentHashMap<String, Object>(256);

/** Кэш синглтон-фабрик: имя бина --> ObjectFactory */
private final Map<String, ObjectFactory<?>> singletonFactories = new HashMap<String, ObjectFactory<?>>(16);

/** Кэш ранних синглтон-объектов: имя бина --> экземпляр бина */
private final Map<String, Object> earlySingletonObjects = new HashMap<String, Object>(16);

Эти три уровня кэширования представляют собой:

singletonFactories: кэш синглтон-фабрик earlySingletonObjects: кэш ранних синглтон-объектов singletonObjects: кэш синглтон-объектов

Три уровня кэширования в Spring

При запуске Spring используются три карты, известные как три уровня кэширования.

Иллюстрация

Процесс запуска Spring включает следующие шаги:

  1. Создание beanFactory и загрузка конфигурационных файлов
  2. Парсинг конфигурационных файлов и преобразование в beanDefinition, получение всех свойств, зависимостей и необходимых обработчиков для инициализации бинов
  3. Обновление beanFactory-контейнера и инициализация всех синглтон-бинов
  4. Регистрация всех синглтон-бинов и возврат доступного контейнера, обычно это расширенный applicationContext

6. Описание SpringSpring используется нами постоянно при работе над проектами, будь то использование SSH или SSM. Внутри Spring есть три основных компонента: IOC (Inversion of Control) или инверсия управления, DI (Dependency Injection) или внедрение зависимостей и AOP (Aspect-Oriented Programming) или ориентированное на аспекты программирование.Сначала я расскажу о IOC. IOC представляет собой контроль перевода внутри Spring, где управление классами передается Spring. При использовании мы указываем бины в конфигурационном файле Spring, включая полное имя класса и его параметры. Таким образом, Spring использует механизм рефлексии для создания экземпляра класса и помещает его в контейнер Spring.

При использовании этого механизма рекомендуется использовать DI или внедрение зависимостей. Мы можем внедрять нужные нам классы в нужные места, используя различные способы внедрения: конструкторное внедрение, внедрение через get/set методы и аннотации. Сейчас мы чаще всего используем аннотации @Autowired или @Resource. Затем следует программирование с использованием аспектов (AOP), которое позволяет улучшить функциональность кода без изменения исходного кода. Мы конфигурируем точки среза в конфигурационных файлах, а затем реализуем логику аспекта для усиления кода. Усиление кода может включать улучшение логики до выполнения среза, во время выполнения и после выполнения. Это позволяет не менять исходный код. В наших проектах это обычно используется для проверки прав доступа, логирования и управления транзакциями.

7. Реализация принципов AOPПо моему мнению, основа реализации AOP в Spring — это динамическое прокси, которое можно увидеть в исходном коде. Динамическое прокси означает, что AOP-фреймворк не модифицирует байт-код, а каждый раз при запуске временно создает объект AOP в памяти, содержащий все методы целевого объекта. В определённых точках среза добавляется усиление, и вызывается оригинальный метод объекта.В Spring AOP используются два типа динамического прокси: динамическое прокси JDK и динамическое прокси CGLIB:

  • Динамическое прокси JDK предоставляет прокси только для интерфейсов, но не поддерживает прокси для классов. Основные компоненты — это интерфейс InvocationHandler и класс Proxy. Интерфейс InvocationHandler использует метод invoke() для отражательного вызова методов целевого класса, динамически объединяя вертикальное и горизонтальное сечение. Затем класс Proxy использует InvocationHandler для динамического создания экземпляра, соответствующего интерфейсу, и создания прокси-объекта для целевого класса.
  • Если прокси-класс не реализует интерфейс InvocationHandler, то Spring AOP выбирает использовать CGLIB для динамического прокси-объекта целевого класса. CGLIB (Code Generation Library) — это библиотека для генерации кода, которая позволяет создавать временный подкласс для указанного класса и переопределять определенные методы, добавляя усиление. CGLIB использует наследование для создания динамического прокси, поэтому если класс помечен как final, его нельзя использовать для динамического прокси. Однако в наших бизнес-сценариях мы не сталкиваемся с прокси-объектами для final-классов. Большинство прокси-объектов создаются для контроллеров для реализации проверки прав доступа и логирования, а также для сервисов для управления транзакциями.## 8. Какие способы внедрения зависимостей существуют в Spring, и что они собой представляют?

1) Внедрение через конструктор

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

2) Внедрение через сеттеры

IoC-сервис провайдер внедряет зависимые объекты в зависимости путем вызова предоставленных сеттеров для членских переменных. Преимущества: Гибкость. Можно выборочно внедрять нужные объекты. Недостатки: После завершения инициализации зависимых объектов, но до внедрения зависимостей, последние еще не доступны для использования.

3) Внедрение через интерфейсыЗависимый класс должен реализовать указанный интерфейс и реализовать функцию внутри этого интерфейса, которая используется для внедрения зависимости. Аргументом этой функции является объект, который требуется внедрить.

Преимущества: Имена интерфейсов и функций не имеют значения, важно лишь то, что аргумент функции представляет тип внедряемого объекта. Недостатки: Слишком инвазивно, не рекомендуется к использованию. Примечание: Что такое инвазивность? Если класс A использует функцию, предоставленную другим классом, и для использования этой функции требуется добавить дополнительный код в свой класс, это и есть инвазивность.## 9. Как настроить переадресацию и перенаправление в Spring MVC?

(1) Перенаправление: добавьте forward: перед значением возврата, например "forward:user.do?name=method4". (2) Переадресация: добавьте redirect: перед значением возврата, например "redirect:http://www.baidu.com".

10. Объясните жизненный цикл бинов Spring.

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

11. Объясните различные области действия бинов, поддерживаемые Spring.

Бины в контексте Spring могут быть разделены на пять областей действия:(1) singleton: По умолчанию, в каждом контексте существует только один экземпляр бина, управляемый BeanFactory. (2) prototype: Для каждого запроса бина предоставляется отдельный экземпляр. (3) request: Для каждого сетевого запроса создаётся отдельный экземпляр; после завершения запроса бин становится недействительным и подлежит сборке мусора. (4) session: Аналогично области действия request, но гарантирует наличие одного экземпляра бина для каждой сессии; после истечения срока действия сессии, бин становится недействительным. (5) global-session: Глобальная область действия, глобальная сессия связана с приложениями Portlet. Когда ваше приложение работает в контейнере Portlet, оно может содержать множество Portlet. Если вы хотите объявить общие глобальные переменные для всех Portlet, эти переменные должны храниться в глобальной сессии. Глобальная область действия аналогична области действия сессии в сервлетах.## 12. Какие паттерны проектирования используются в фреймворке Spring?

(1) Фабричный метод: BeanFactory представляет собой реализацию простого фабричного метода, используемую для создания экземпляров объектов;
(2) Одиночка: Базовый режим Beans — это одиночный паттерн;
(3) Прокси: Функциональность AOP в Spring использует динамическое проксирование JDK и технологию генерации байт-кодов CGLIB;
(4) Шаблонный метод: используется для решения проблемы повторяющегося кода. Например, RestTemplate, JmsTemplate, JpaTemplate.
(5) Наблюдатель: Определяет отношение "один ко многим" между объектами, при котором когда состояние одного объекта изменяется, все зависящие от него объекты получают уведомление и автоматически обновляются. Например, реализация слушателей в Spring — ApplicationListener.

13. Процесс внедрения Spring Bean

  1. Получение beanFactory
  2. Реализация интерфейса BeanPostProcessor
  3. Создание экземпляра целевого bean с помощью рефлексии
  4. Внедрение свойств в целевой bean
  5. Если реализован интерфейс BeanNameAware, то вызывается метод setBeanName для установки id
  6. Если реализован интерфейс BeanFactoryAware, то вызывается метод setBeanFactory для установки factory
  7. Вызов метода postProcessorBeforeInitialization у beanPostProcessor
  8. Инициализация, если реализован интерфейс InitializingBean, то вызывается метод afterPropertiesSet(), затем вызывается пользовательский init-method
  9. Вызов метода postProcessorAfterInitialization у beanPostProcessor
  10. Вызов метода destroy() через DisposableBean или пользовательский метод destroy## 14. Встроенные утилиты Spring

При работе с Spring Boot можно использовать встроенные утилиты для автоматического конфигурирования приложения. Например, spring-boot-devtools предоставляет удобные инструменты для разработки, такие как автообновление приложения при сохранении изменений в коде.

spring-boot-devtools

spring-boot-devtools — это набор утилит, который помогает упростить процесс разработки. Он включает в себя следующие возможности:

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

Для использования spring-boot-devtools, необходимо добавить его в список зависимостей вашего проекта. Это можно сделать, добавив следующую строку в файл pom.xml:

<dependency>
    <groupId>org.springframework.boot</groupId>
    <artifactId>spring-boot-devtools</artifactId>
    <scope>runtime</scope>
</dependency>

Также можно использовать spring-boot-maven-plugin для управления жизненным циклом сборки:

<plugin>
    <groupId>org.springframework.boot</groupId>
    <artifactId>spring-boot-maven-plugin</artifactId>
</plugin>

Пример использования

Пример использования spring-boot-devtools может выглядеть следующим образом:

import org.springframework.boot.SpringApplication;
import org.springframework.boot.autoconfigure.SpringBootApplication;

@SpringBootApplication
public class MyApp {
    public static void main(String[] args) {
        SpringApplication.run(MyApp.class, args);
    }
}

Этот пример демонстрирует базовую конфигурацию приложения с использованием spring-boot-devtools.

Опубликовать ( 0 )

Вы можете оставить комментарий после Вход в систему

1
https://api.gitlife.ru/oschina-mirror/yangdechao_admin-guage-notes.git
git@api.gitlife.ru:oschina-mirror/yangdechao_admin-guage-notes.git
oschina-mirror
yangdechao_admin-guage-notes
yangdechao_admin-guage-notes
master