Java SPI 메커니즘 지식 요약

머리말
여러분 이 지금 회사 에 복귀 하 셨 는 지 모 르 겠 습 니 다.저 는 3 주 가까이 재 택 근 무 를 했 고 한 달 넘 게 집에 있 었 습 니 다.다행히 업무 가 아무런 영향 을 받 지 않 았 기 때문에 저 는 개인 적 으로 원 격 업무 와 IT 업계 가 매우 적합 하 다 고 생각 했 습 니 다.그 동안 업무 효율 이 사무실 보다 높 았 고 우리 회사 의 업무 가 해외 에 있 기 때문에 전염병 발생 상황 은 거의 많은 영향 을 미 치지 않 았 습 니 다.
멀 어 졌 습 니 다.이번 에는 자바 의 SPI 체 제 를 여러분 과 공유 하고 싶 습 니 다.
아직 보지 못 한 친구 의 나 는 먼저 전망 요점 을 만 들 었 다.그 당시 의 수요:
나 는 SpringMVC 와 유사 하지만 매우 가 벼 운 http 프레임 워 크 cicada 를 실현 했다.그 중에서 도 당연히 IOC 용기 가 필요 하고 모든 단일 bean 을 저장 할 수 있다.
이 IOC 용기 의 실현 은 여러 가지 방식 이 있 고 심지어 다른 사람 이 실현 할 수 있 도록 인 터 페 이 스 를 제공 할 수 있 기 를 바 랍 니 다.물론 이 IOC 용 기 를 전환 하 는 과정 은 하 드 인 코딩 이 존재 하지 않 을 것 이다.즉,여기 서 언급 한 플러그 인 이다.내 가 A 의 실현 방식 을 사용 하고 싶 을 때 나 는 A 의 jar 가방 을 도입 하고 B 를 사용 할 때 B 의 가방 을 도입 한다.

먼저 두 번 의 실현 차 이 를 보 여 드 리 겠 습 니 다.먼저 코드 의 간결 성 으로 볼 때 SPI 가 한 수 위 입 니 다.
SPI 가 뭐야?
구체 적 으로 분석 하기 전에 SPI 가 뭔 지 알 아 볼 까요?
우선 Service provider interface 의 약자 이 고 중국어 로 번역 하면 서비스 가 발견 인 터 페 이 스 를 제공 하 는 것 입 니 다.
그러나 여기 서 이 명사 에 헷 갈 리 지 마 세 요.이곳 의 서비스 발견 은 우리 가 자주 듣 는 마이크로 서비스 중의 서비스 발견 과 동일시 할 수 없습니다.
앞에서 언급 한 것 처럼 IOC 용기 에 대한 다양한 실현 방식 A,B,C(이 를 서비스 로 이해 할 수 있 음)는 운영 할 때 어떤 구체 적 인 실현 을 사용 해 야 하 는 지 알 아야 한다.
사실은 본질 적 으로 이것 은 전형 적 인 인터페이스 프로 그래 밍 이다.이 점 은 우리 가 프로 그래 밍 을 처음 배 웠 을 때 반복 적 으로 강조 되 었 다.
SPI 실천
다음은 SPI 를 이용 하여 방금 언급 한 IOC 용 기 를 뽑 을 수 있 는 방법 을 알 아 보 겠 습 니 다.
방금 SPI 의 본질 이 인터페이스 프로 그래 밍 이 라 고 언급 했 으 니 자 연 스 럽 게 우 리 는 먼저 인 터 페 이 스 를 정의 해 야 한다.

그 중 에는 빈 용기 에 필요 한 작업 이 포함 되 어 있 습 니 다.등록,획득,방출 bean.
다른 사람 도 자신의 IOC 용 기 를 실현 할 수 있 도록 이 인 터 페 이 스 를 하나의 Module 에 단독으로 넣 어 다른 사람 이 도입 하여 실현 할 수 있 도록 합 니 다.

그래서 제 가 하나의 IOC 용 기 를 실현 하려 면 모듈 을 새로 만 든 다음 에 아까 모듈 을 도입 하고 Cicada Bean Factory 인 터 페 이 스 를 실현 하면 됩 니 다.
물론 가장 중요 한 것 은 resources 디 렉 터 리 에 META-INF/services/top.crossoverjie.cicada.base.bean.icadaBean Factory 파일 을 새로 만들어 야 합 니 다.파일 이름 은 우리 가 이전에 정의 한 인터페이스의 전체 제한 이름(SPI 규범)이 어야 합 니 다.

그 중의 내용 은 바로 우리 자신 이 실현 하 는 모든 제한 이름 이다.
top.crossoverjie.cicada.bean.ioc.CicadaIoc
최종 적 으로 이곳 의 모든 한정 명 을 통 해 생 성 대상 을 반사 할 것 이 라 고 상상 할 수 있다.
다만 이 과정 에서 자바 는 API 차단 을 제 공 했 습 니 다.

public static CicadaBeanFactory getCicadaBeanFactory() {
    ServiceLoader<CicadaBeanFactory> cicadaBeanFactories = ServiceLoader.load(CicadaBeanFactory.class);
    if (cicadaBeanFactories.iterator().hasNext()){
      return cicadaBeanFactories.iterator().next() ;
    }

    return new CicadaDefaultBean();
  }

classpath 에 우리 가 방금 실현 한 클래스(실현 클래스 를 도입 한 jar 패키지)가 존재 하면 자바 util.Service Loader 도구 클래스 를 통 해 모든 실현 클래스 를 찾 을 수 있 습 니 다.
일 부 를 준비 한 후에 사용 하 는 것 은 자 연 스 럽 게 매우 간단 하 다.

<dependency>
    <groupId>top.crossoverjie.opensource</groupId>
    <artifactId>cicada-ioc</artifactId>
    <version>2.0.4</version>
  </dependency>

우 리 는 이 의존 만 도입 하면 그것 의 실현 을 사용 할 수 있다.우리 가 실현 방식 을 바 꾸 려 면 하나의 의존 만 바 꾸 면 된다.
이렇게 해서 한 줄 의 코드 를 수정 하지 않 고 유연 하 게 뽑 아서 IOC 용 기 를 선택 할 수 있 게 되 었 다.
SPI 의 다른 응용 프로그램
평소에 SPI 를 직접 사용 하여 업 무 를 실현 하 지 는 않 지만 사실은 우리 가 사용 한 절대 다수의 프레임 워 크 는 SPI 인 터 페 이 스 를 제공 하여 사용자 가 자신의 기능 을 확장 하 는 데 편리 하도록 한다.
예 를 들 어 Dubbo 에서 일련의 확장 을 제공 합 니 다:
같은 유형의 RPC 프레임 워 크 motan 에서 도 응답 확장 을 제공 합 니 다:
그들의 사용 방식 은 모두 자바 SPI 와 매우 유사 하지만 원리 가 약간 다 를 뿐 아니 라 일부 기능 도 추가 되 었 다.
예 를 들 어 motan 의 spi 가 단일 사례 로 허용 되 는 지 등 이다.
예 를 들 어 MySQL 의 드라이버 패키지 도 SPI 를 이용 하여 자신의 연결 논 리 를 실현 한다.

총결산
자바 자체 의 SPI 도 사실 약간의 결함 이 있다.예 를 들 어:
모든 구현 클래스 를 옮 겨 다 니 는 효율 이 낮 습 니 다.여러 개의 ServiceLoader 가 동시에 load 할 때 병발 문제 가 발생 할 수 있 습 니 다.
마지막 으로 SPI 는 어떤 심오 한 기술 이 아니 라 본질 적 으로 인 터 페 이 스 를 대상 으로 프로 그래 밍 하 는 것 이다.인터페이스 자 체 를 대상 으로 하 는 것 은 우리 의 일상적인 개발 에 필수 적 인 기능 이기 때문에 SPI 를 사용 하 는 것 도 매우 유용 하 다.
본 논문 의 모든 소스 코드:
https://github.com/TogetherOS/cicada
자바 SPI 메커니즘 에 대한 지식 을 정리 한 이 글 은 여기까지 소개 되 었 습 니 다.더 많은 자바 SPI 메커니즘 에 관 한 내용 은 우리 의 이전 글 을 검색 하거나 아래 의 관련 글 을 계속 조회 하 시기 바 랍 니 다.앞으로 많은 응원 바 랍 니 다!