몇 분이면 Spring 프레임워크의 이론적 지식을 빠르게 이해할 수 있습니다!

1. Spring에 대한 두 가지 핵심 이해

Spring의 두 가지 핵심은 IOC(Inversion of Control)와 AOP(Aspect-Oriented Programming)입니다.

IOC Inversion of Control: 사실 객체 관리 권한이 Spring에게 넘어가고 있다. 스프링 컨테이너는 구성 파일에 따라 처리하며, 인스턴스를 생성하고 인스턴스 간의 종속성을 관리하며 객체 간의 느슨한 결합도 기능을 재사용하는 데 도움이 됩니다. 직설적으로 IOC는 NEW로 이동하지 않고 객체 생성을 허용하며, 이는 우리가 제공하는 구성 파일에 따라 Spring에서 자동으로 생성할 수 있으며 객체가 필요할 때 컨테이너에서 직접 가져올 수 있습니다.

클래스의 바이트코드 위치와 정보는 Spring 설정 파일에 설정되며, 컨테이너가 생성되면 바이트코드 정보를 식별하기 위해 설정 파일이 로드되고 리플렉션을 통해 클래스의 객체가 생성된다.

IOC 주입 방법: setter 방법, 생성자, 주석 방법

AOP AOP 관점 지향 프로그래밍: 사실 비즈니스와 관련이 없지만 여러 개체에 영향을 미치는 공개 동작 및 논리 추출을 재사용 가능한 모듈로 캡슐화합니다.이 모듈은 실제로 관점입니다. 예: 로그 관리 등 Spring AOP는 동적프록시를 사용하는데 동적프록시는 AOP 프레임워크가 바이트코드를 수정하지 않고 메서드가 실행될 때마다 메모리에 일시적으로 메소드에 대한 AOP객체를 생성하는 것을 의미한다. 특정 절단 지점에서 수행되고 원래 개체의 메서드가 다시 호출됩니다.

2. Spring은 여러 범위의 Bean을 지원합니다.

(1) 싱글톤: 기본값은 싱글톤 빈이며 컨테이너에는 하나의 빈만 있습니다.

(2) Propotype: 객체가 인스턴스화될 때마다 빈이 생성된다.

(3) 요청: 요청은 빈을 생성하고 가비지 수집 컨테이너는 요청이 끝난 후 이를 재활용합니다.

(4) 세션: 요청과 유사하게 세션이 빈을 공유하고 해당 빈은 세션 또는 세션이 종료된 후 재활용됩니다.

(5) global-session: 전역 범위, 모든 세션이 인스턴스를 공유합니다. 모든 세션이 공유하는 스토리지 변수를 선언하려면 전역 변수를 global-session에 저장할 수 있습니다.

3. BeanFactory와 ApplicationContext의 차이점

beanFactory는 Spring의 최상위 인터페이스로 Spring컨테이너의 기본기능을 구현하며 호출하기가 매우 번거롭고 일반적으로 Spring자체에 사용된다. 프로젝트가 시작되면 Bean은 즉시 인스턴스화되지 않고 호출될 때만 인스턴스화됩니다.

applicationContext는 일부 기능을 확장하는 beanFactory의 하위 인터페이스입니다. 프로젝트가 시작되자마자 bean을 로드하여 Spring 컨테이너에 넣은 다음 사용할 때 가져옵니다.

4. Spring 프레임워크에서 사용하는 디자인 패턴

(1) 팩토리 모드: beanFactory 내부는 빈 생산을 위해 간단한 팩토리 모드를 사용합니다.

(2) 싱글톤 모드: 빈은 기본적으로 싱글톤이며 컨테이너에는 하나의 빈만 있습니다.

(3) 프록시 모드: Spring의 AOP는 JDK 동적 프록시 및 CGLIB 바이트코드 기술을 통해 구현됩니다.

(4) 관찰자 방법: 개체 키의 일대다 종속성을 정의합니다. 개체의 속성이 변경되면 그에 따라 다른 종속 개체에 알리고 업데이트할 수 있습니다. Spring의 리스너는 ApplicationListener입니다.

(5) 템플릿 방법: JpaTemplate 및 RestTemplate과 같은 코드 재사용을 실현합니다.

5. Spring 트랜잭션의 구현 방법 및 원리

Spring 트랜잭션의 본질은 데이터베이스의 트랜잭션 지원인데 데이터베이스가 트랜잭션을 지원하지 않으면 Spring은 트랜잭션을 구현할 수 없습니다. 데이터베이스는 binlog 및 relog를 사용하여 데이터 제출 및 롤백을 구현합니다.

구현 방법은 다음과 같습니다.

(1) 프로그래밍 트랜잭션: begintransactionManager(), commit() 및 rollback()과 같은 트랜잭션 관리 메서드 구현.

(2) 선언적 트랜잭션: @Transactional 어노테이션으로 구현.

6. Spring 알림 유형 및 실행

(1) 사전 알림 유형: Pointcut이 실행되기 전에 실행됩니다.

(2) 사후통지형 : Pointcut이 정상적으로 실행된 후 실행된다.

(3) 예외 알림 유형: 컷 포인트에서 예외가 발생했을 때 실행됩니다.

(4) 최종 어드바이스 유형: 포인트컷에서 최종 실행.

(5) 주변 알림 유형: 프로그래머는 다른 알림 타이밍 문제를 해결하기 위해 코딩을 통해 알림 설정을 스스로 정의할 수 있습니다.

7. Spring 객체의 기본값이 단일 인스턴스인지 다중 인스턴스인지 여부 및 싱글톤 빈에 스레드 안전 문제가 있는지 여부

Spring 객체는 기본적으로 싱글톤이지만 여러 인스턴스로 설정할 수 있습니다.

싱글톤 빈 객체에 해당하는 클래스는 가변 멤버 변수를 가질 수 있으며 멤버 변수의 값을 변경하기 위한 스레드가 있을 때 다중 스레드가 빈을 작동시켜 스레드 안전 문제를 일으킬 수 있습니다. 그 이유는 다중 스레드 작업이 멤버 변수를 변경하면 다른 스레드가 Bean에 액세스할 수 없어 데이터 혼란이 발생하기 때문입니다.

Bean 객체에 변수 멤버 변수를 설정하지 않고 ThreadLocal 변수를 정의하고 모든 변수 멤버 변수를 변수 안에 넣을 수 있습니다.

8. @Resource와 @Autowired 의존성 주입의 차이점

@Resource Spring에서 제공하는 Annotation으로 기본적으로 이름으로 어셈블되며 이름으로 일치하는 빈이 없으면 타입으로 어셈블하고 이름으로 찾을 수 없으면 에러를 보고한다. 단, name 속성을 통해 실행을 지정하면 이름에 따라 어셈블만 되고, 찾지 못하면 에러가 발생하며, 타입 클래스에 따라 어셈블되지 않는다는 점을 알아두어야 한다.

@Autowried 기본적으로 java에서 제공되며 기본적으로 type에 따라 어셈블됨 종속 객체는 기본적으로 존재해야 하며 비어 있는 경우 required를 false로 설정해야 함 이름으로 어셈블리를 구현하려면 @Qualifier와 함께 지정된 이름을 사용해야 합니다.

9. @Qualifier 사용 시나리오

반드시 @Autowired와 함께 사용해야 하며, 단독으로는 사용할 수 없으며, 둘을 조합하여 이름으로 어셈블리를 구현하여 실제로 @Resource와 동일한 기능을 수행한다.

10.Spring의 일반적인 주석

@Component: 개체 인스턴스화를 위해 다양한 계층에서 사용할 수 있습니다.

@Controller: 제어 계층용, 개체 인스턴스화용

@Service: 비즈니스 계층용, 개체 인스턴스화용

@Repository: DAO 레이어용, 객체 인스턴스화용

@Value: 단순 속성에 대한 종속성 주입

@Resource: 개체의 조립을 구현하기 위해 기본값은 이름에 따라 조립하는 것이며, 찾을 수 없는 경우 유형에 따라 조립할 수 있습니다.

@Autowried: 객체의 조립을 실현하기 위해 기본값은 유형에 따라 조립하는 것입니다. 찾을 수 없으면 예외가 발생합니다.

@Qualifier: 이름으로 어셈블리를 달성하기 위해 @Autowried와 함께 사용됩니다.

@Bean: 메소드에 표시하고 메소드에 bean 객체를 생성하도록 지시한 다음 관리를 위해 Spring에 전달하고 컨테이너에 넣습니다.

@ComponentScan: 컴포넌트 스캔

@Configiration: 이 주석을 갖는 것은 구성 클래스로 간주됩니다. 시스템이 시작되면 Spring은 생성해야 하는 객체를 생성하고 빈 컨테이너에 넣고 필요할 때 가져옵니다.

@Transactional: 메서드에 배치, 트랜잭션 관리 기능 포함

@Import: 구성 클래스에 다른 구성 클래스의 내용을 소개합니다.

@PostConstruct, @PreDestory: Spring 객체가 생성된 후 소멸되기 전에 수행해야 하는 작업을 설정하는 데 사용됩니다.

@PropertySource: 다른 속성 구성 파일을 소개하는 데 사용됩니다.

11. Spring의 트랜잭션 전파 동작

트랜잭션의 전파 동작은 실제로 여러 트랜잭션이 동시에 존재할 때 Spring이 이러한 트랜잭션을 처리하는 방법을 나타냅니다.

(1) propagation_requried: 현재 거래가 있으면 조인하고, 거래가 없으면 새로운 거래를 생성한다.

(2) propagation_support: 현재 트랜잭션을 지원합니다. 현재 트랜잭션이 있으면 조인하고, 트랜잭션이 없으면 논트랜잭션으로 실행한다.

(3) propagation_not_support: 논트랜잭션으로 실행된다. 트랜잭션이 현재 존재하는 경우 보류 중인 트랜잭션은 트랜잭션이 아닌 방식으로 실행됩니다.

(4) propagation_never: 논트랜잭션으로 실행한다. 트랜잭션이 있으면 예외가 발생합니다.

(5) propagation_requries_new: 현재 트랜잭션이 있든 없든 상관없이 새로운 트랜잭션을 생성합니다.

(6) propagation_mandatory: 현재 트랜잭션을 지원하며 현재 트랜잭션이 있으면 트랜잭션에 참여하고 존재하지 않으면 예외를 제거합니다.

(7) propagation_nested: 현재 트랜잭션이 있으면 중첩된 트랜잭션에서 실행한다. 트랜잭션이 없으면 필요한 속성에 따라 실행합니다.

12. Spring의 격리 수준

(1) isolation_default: 데이터베이스의 기본 격리 수준을 사용하는 PlatfromTransactionManager의 기본 트랜잭션 격리입니다.

(2) isolation_read_uncommitted: 커밋되지 않은 읽기, 다른 트랜잭션이 이 트랜잭션의 커밋되지 않은 데이터를 볼 수 있도록 합니다.

(3) isolation_read_committed: 커밋된 읽기, 한 트랜잭션에서 수정한 데이터가 커밋된 후에만 다른 트랜잭션에서 읽을 수 있도록 보장하고 트랜잭션에서 기존 레코드의 업데이트를 볼 수 있습니다. 더티 데이터 문제를 해결하십시오.

(4) isolation_repeatable_read: 한 트랜잭션에 의해 수정된 데이터를 커밋 후에만 다른 트랜잭션에서 읽을 수 있지만 트랜잭션에 의한 기존 레코드의 업데이트는 볼 수 없도록 반복 읽기. 행 테이블.

(5) isolation_serializable: 트랜잭션은 실행 중에 다른 트랜잭션이 데이터베이스에 수행한 업데이트를 볼 수 없습니다. 표준 잠금.

추천

출처blog.csdn.net/lf21qp/article/details/131401317