운영 및 유지 관리 팀에서는 나에게 SpringBoot 시작 속도를 최적화하라고 요청했고 이것이 바로 내가 한 일입니다!

Spring Boot는 의심할 여지 없이 Java 백엔드 개발을 위한 최고의 프레임워크입니다. Spring Boot를 기반으로 하며 완전한 도구 체인과 다양한 스타터를 갖추고 있습니다. 일상적인 비즈니스 개발을 위해서는 바퀴가 완성되었다고 말할 수 있습니다.

그러나 마이크로서비스와 클라우드 네이티브 시대의 인기로 인해 Spring Boot 애플리케이션은 몇 가지 문제를 노출했으며, 그보다 더 두드러진 문제는 다음과 같습니다. 메모리

• 클라우드 네이티브 애플리케이션은 시작 속도에 대한 요구 사항이 상대적으로 높습니다. 수평적 확장이 필요한 경우 이러한 새 인스턴스는 가능한 한 빨리 새 요청을 처리할 수 있을 만큼 짧은 시간 내에 시작되어야 합니다.
• 클라우드 네이티브 애플리케이션은 런타임 중에 사용하기 위해 가능한 한 적은 리소스가 필요합니다. 단일 인스턴스가 차지하는 리소스를 최대한 줄이면 동일한 비용으로 더 많은 액세스 요청을 지원할 수 있습니다.
• 클라우드 네이티브 애플리케이션에는 더 작은 포장 크기가 필요합니다. 클라우드 네이티브 애플리케이션은 컨테이너 이미지 형태로 패키징됩니다. 애플리케이션 이미지의 크기가 클수록 필요한 저장 공간도 커지고, 이미지를 푸시하고 가져오는 데 시간이 더 오래 걸립니다.
• 사실 대부분의 시작 시간은 Spring이 다양한 Bean을 로드해야 하기 때문에 시작 속도가 느려진다는 사실로 인해 발생한다는 것을 모두 알고 있습니다.
1. Bean 초기화 지연
• 일반적으로 , SpringBoot에는 데이터베이스 연결 설정, 초기 스레드 풀 생성 등과 같이 시간이 많이 걸리는 작업이 많이 있으므로 시작 속도를 최적화하기 위해 이러한 작업의 초기화를 지연할 수 있습니다. spring.main.lazy-initialization 속성은 Spring Boot 버전 2.2 이후에 도입되었습니다. true로 구성하면 모든 Bean이 느리게 초기화됩니다.

  spring:main:lazy-initialization: true

로컬에서 지연된 초기화를 켜면 시작이 1~2초 더 빨라질 수 있습니다.

Environment

Configuration≒10.3s

(평균 10회) 시작 속도	springboot2+jdk1.8
		Bean의 지연 초기화	≒8.63초

二、创建扫描索引

Spring5 之后提供了spring-context-indexer功能，可以通过在编译时创建一个静态候选列表来提高大型应用程序的启动性能。

先看官方的解释：

在项目中使用了@Indexed之后，编译打包的时候会在项目中自动生成META-INT/spring.components文件。

当Spring应用上下文执行ComponentScan扫描时，META-INT/spring.components将会被CandidateComponentsIndexLoader 读取并加载，转换为CandidateComponentsIndex对象，这样的话@ComponentScan不在扫描指定的package，而是读取CandidateComponentsIndex对象，从而达到提升性能的目的.

我们只需要将依赖引入，然后在启动类上使用@Indexed注解即可。这样在程序编译打包之后会生成
META-INT/spring.components文件，当执行@ComponentScan扫描类时，会读取索引文件，提高扫描速度。

<dependency>	<groupid>org.springframework</groupid>	<artifactid>spring-context-indexer</artifactid>	<optional>true</optional></dependency>

@Indexed@SpringBootApplicationpublic class Application {public static void main(String[] args) {SpringApplication.run(Application.class, args);}}

环境	配置	(十次平均值)启动速度
springboot2+jdk1.8		≈10.3s
	+延迟初始化Bean	≈8.63s
	+创建扫描索引	≈7.7s

기타 팁:

1. 클래스를 스캔할 때 @ComponentScan @SpringBootApplication의 범위를 줄이세요

2 Spring Boot의 JMX 모니터링을 끄고 spring.jmx.enabled=false

3을 설정하세요. noverify, 클래스를 확인하지 마세요.

4. 시작 시 로드할 필요가 없는 빈의 로딩을 지연하세요. 5. Spring Boot의 전역 지연 로딩을 사용하세요.

5. AOPQ 측면에 주석을 사용하지 마세요. 시작 시 스캔 7. 일부 엔드포인트 모니터링 기능 끄기

6. 프로젝트의 불필요한 jar 종속성을 제외

7. Swagger가 인터페이스를 스캔할 때 특정 경로 아래의 클래스만 스캔하도록 지정 10. Feign 스캔 클라이언트 인터페이스는 패키지 스캐닝 범위를 좁힙니다

이 시점에서 시작 속도가 가장 최적화되어 있다고 간주해야 하지만 여전히 대용량 메모리 사용량이 문제입니다

3. jdk17 업그레이드

물론 jdk도 이 분야에서 많은 노력을 기울였습니다:

대량 메모리 사용량은 주로 메모리 사용량으로 인해 발생합니다. 운영 체제는 앞으로 반환되지 않으며 점차 개선되고 있습니다.

• G1 JDK12 이상이 지원됩니다
• ZGC JDK13 이상 지원

Java 언어의 기능을 기반으로 하며 Spring Boot의 일부 구현 방법에서는 G1/ZGC의 사용하지 않는 메모리를 켜서 반환하더라도 이를 결정합니다. 운영 체제가 시간이 지남에 따라 Spring Boot의 메모리 사용량은 여전히 ​​Golang과 같은 컴파일 언어의 메모리 사용량보다 훨씬 큽니다.

그래서 Java가 클라우드 네이티브 시대의 문제를 해결하려는 경우 현재 솔루션은 Quarkus이든 Micronaut이든 기본적으로 GraalVM을 기반으로 합니다.

그럼 Spring Boot에도 비슷한 솔루션이 있나요? : spring-graalvm-native

4. SpringBoot3

업그레이드는 springBoo6/SpringBoot3의 매우 중요한 기능으로, SpringBoot 애플리케이션을 로컬 실행 가능 이미지 파일로 컴파일하는 것을 지원합니다. 시작 속도, 최대 성능 및 메모리 사용량 감소.

위 내용은 운영 및 유지 관리 팀에서는 나에게 SpringBoot 시작 속도를 최적화하라고 요청했고 이것이 바로 내가 한 일입니다!의 상세 내용입니다. 자세한 내용은 PHP 중국어 웹사이트의 기타 관련 기사를 참조하세요!