1109 thread 실습하기!

대기큐 사이즈를 0로, 스레드풀사이즈를 100으로 한정해놓고 스레드 1000개를 동시에 보냈다.!!

그랬더니 - 더이상 요청을 받아들일수없다는 에러 메시지 출력!!오오오.

1107 threadPoolExecutor

 

for 문안에 execute를 열번. 제각각의 스레드가 형성되며

동시성문제 및 결과순서도 뒤죽박죽이 되는 것을 확인할수있다. ID값이 중복되어서 나타나고있음.

또한 sysout으로 찍을때 서로 화면을 빼앗으려는 경합이 발생한다.

메소드 수행도중에 화면에 찍고 싶은데 - 다른 스레드가 치고 들어와서 순서빼앗고 지가 먼저 찍고 계속 반복. System.out.println 메소드가 경합에서 밀려서 나중에서야 찍힌다. 

(근데 희한하다. service안에서 부르는 메소드도 똑같은 Syso를 사용하는데 다 먼저찍히네? ) 

execute 안에서 열번 같은 메소드 호출.

하나의 스레드가 수행하므로 id값과 순서가 순차적으로 나타난다. 동시성문제x

1030 싱글톤 스코프 테스트!

 빈을 가져오는 방법

1. ApplicationContext에서 직접 getBean하기 -> 로우레벨의 기술(나는 스프링을 사용중이다!~) 라는 것을 들켜버리므로 좋지 않다. 

2. Factory클래스를 만들기

- ObjectFactoryCreatingFactoryBean을 @Bean으로 올린다.

인터페이스가 있고 - 이 인터페이스를 구현한 ObjectFactoryCreatingFactoryBean이 있음. 해당 클래스의 메소드 setTargetName 이름을 넣어주고 빈으로 등록해서 올린다. 사용할때는 인터페이스 타입으로 @Autowired받으면 됨. 다만 스프링이 정의해둔 인터페이스를 가져다 쓴다는 것이 찜찜할 수 있다. 

어쨌든 그래도 로우레벨을( 어플리케이션콘텍스트) 한번감싸서 팩토리 빈으로 빈을 생성해 주기때문에- 1번보다는 낫다. 빈이 어떤식으로 생성되는지는 몰라도 되기 땜에.

3. Provider<T> 인터페이스 이용하기

해당 인터페이스를 구현한 클래스를 @Bean으로 올리면 됨. Provider<돌려줄 빈타입> 으로 @Autowired받아서사용.

- 재미있었던점!!

첨에 @Configuration으로 안올리고 일반 @Component로 한뒤에 new SingletonScopeBean으로 되돌려주도록 메소드 만들었더니 해당 빈또한 @Component로 돌렸음에도 불구하고 새로운 빈이 또 생겨나서 싱글톤이 아니게되었다!!

그래서 @Autowired로 바꾼뒤에 돌려주게 만들었더니 이제 싱글톤빈으로 돌려줌. 그래서 @보통은 @Configuration으로 붙인담에 그런식으루 쓰는구나 싶었다.. 헷갈리니까?

1026 스프링 @Configuration 싱글톤 테스트

 

Configuration어노테이션의 독특한 점을 발견할수있다.

설령 해당 메소드로 직접불렀다고 하더라도!! 싱글톤임을 보장해준다. @Configuraiton자체도 그자체로 빈이 된다.

신기한결과 - @Configuration어노테이션을 지우고 실험해보았더니.

hello()메소드로 직접부른 hello1 = hello2객체는 같았다.

그러나 getBean에서 hello를 불러올수는 없었다

?!! 뭐지!! 신기한결과...예상치 못했다

내가 예상한 것은 메소드마다 새로운 hello빈이 생성되는 것이었는데,

해당 클래스(TestConfiguration클래스)안에서의 싱글톤만 보장해주고

@Configuraiton이 아니기때문에 - 스프링 컨텍스트에는 올려주지 않는것!!인듯!!

1012 FactoryBean 만들기

 

스프링이 bean을 등록하는 방식

1. 자바 리플렉션

2. FactoryBean이용.

직접 factorybean클래스를 상속하여 나만의 helloFactoryBean을 만든다. 

hello 오브젝트를 interface만든후 impl클래스 하나 만들고. @Autowired로 받아둔다.

hello factory bean은, 일종의 프록시로 작동한다. hello의 메소드에 invocationHandler를 붙여서- 부가기능을 첨가해줄것이다. 

재미있는 점은. helloFactoryBean을 bean으로 가져왔을때 던져주는 클래스가 helloFactorybean이 아니라, hello클래스라는 점이다. 

확장한다면 hello뿐만이아니라- 다양한 Object클래스를 받을 수 있을 것이다. 

해당 target 클래스의 toString이 불리는 것을 확인할 수있다.

1011 implements 하는 타입의 빈이 여러개 등록된경우

 

스프링은 싱글톤으로 빈등록을 한다.그래서 여러개 implements하는 빈이 있으면 어느쪽을 주어야할지몰라서 에러가 발생하곤 한다. 해결방법은

1 ) @qualified사용하거나

2) 이름을 지정해준다

스프링은 일단 타입으로 찾고 -> 그다음에 이름으로 찾기때문에.. 특정 이름으로 인스턴스변수를 넣어주면 그 객체로 @Autowired해준다. 

Tx의 메소드가 호출된 것을 확인할 수 있다. 

이런식으로 한겹 감싸서 - (프록시 패턴. 혹은 데코레이터 패턴) 부가기능을 제공해줄 수 있다. 

1011 spring boot test

 @RunWith 

@SpringBootTest

로 했을 때의 차이??

이상하게 - @Runwith(SpringBoot4TestRunner.class)로 돌리면 ApplicationContext가 찾아지는데

단순히 @SpringbootTest로 붙이면 못찾더라. 왜지?

테스트 쉽게하라고 만들어준 어노테이션이 아니었던 건가?!!

-----

확인결과

 @Runwith(SpringBoot4TestRunner.class)로 돌리면, 단위테스트. 정말로 test에 필요한 최소한의 클래스만 올려줌. 만약에 @Component등.. bean으로 등록한 애들 가져오고 싶은거면

1. @ContextConfiguration으로 지정해서 - 테스트하고 싶은 클래스들만 가져온다

2.

@BootstrapWith(SpringBootTestContextBootstrapper.class)

이용해서 . 빈들 다 띄울수도 있다.

특히 저 둘 어노테이션들은 @SpringBootTest어노테이션안에 들어가 있음. 그래서 @SpringBootTest를 붙이면 모든 클래스를 올려주는 통합테스트가 된다. 

스프링부트가 만들어주는 각종 AutoConfig하는 클래스들과 내가 만든 모든 빈들 전부 등록해준다. 안으로 들어가보면.. mvc (web일경우.) 부터시작해서 각종 autoconfigure클래스들이 들어오는 걸 확인할 수 있다.

3. @ExtendWith 어노테이션 : JUnit4 -> 5로 확장해줌. 

1006 JUnit 동작원리

 jUnit test시에 - 인스턴스변수가 계속 null이 뜨는 거다. 왜지 - 

이건 분명 jUnit프레임워크 동작원리에 의한것이다 생각. 

JUnit은 매번 테스트 시마다 클래스가 새로 생성된다. 

내가 만든 User객체 - (인스턴스 변수) 도 그때마다 새로 생성되어서. 

Assert를 하는데 null이 뜬다던지 size가 맞지 않는다던지 하였다. 

음!!! 

실험결과

@Before 어노테이션에 뭔가 문제가 있다. 

@Test어노테이션을 걸어서 Assert하면 예상한 결과가 나오는데

@Before을 부르니까 - add () 해서 insert했을때 계속 insert가 하나 밖에 안된다?? 

좀더 JUnit에 대해 공부해야겠음!!!

그리고 인스턴스 변수를 - 각각의 테스트 메소드끼리 공유하지 못한다는 것도 알았다. stateless한 객체 (@Autowired로 넣을수있는, 스프링 빈 같은 애들은 애초부터 무상태니까 괜찮지만) 가 아니면. 인스턴스 변수를 JUnit테스트 메소드에서 건너건너 쓰면 안된다.

하긴 그렇다. 각각의 테스트는 서로에게 영향을 끼치면 안되니까. TDD좀더 공부해야지.

1003 토비의 스프링 - DI

 1. DI란

- 설계단계에서 클래스 레벨의 의존관계를 설정하는 것이 아니라, 런타임시에 의존관계를 설정하는 것.

2. 어떻게 가능한가?

- 설계 단계에서는 - 즉, 클래스레벨에서는 - 인터페이스만 의존하게 만들어두고, 런타임시에 factory혹은 컨테이너가 적절한 클래스를 생성하여, 생성자의 파라메터로 넣어주는 방식을 취한다. 

- 이것은 @Configuration만 바꾸어주면 가능하므로 - 코드를 일일이 고치지 않고, @Configuration의 수정만으로 의존관계 설정을 바꿀수있다!!

- 클래스간의 의존관계가아니라, 런타임시의 의존관계!! 동적 생성.

3. 응용

- 어떻게 응용할 수 있을까?

1) - 이를테면 db커넥션연결을 test시와 prod시를 분리하고 싶을 때 - 해당 커넥션에 따로따로 클래스를 만들고, @Configuraiton만 갈아끼운다는 전략이 있을수있다.

2)

- 또한 이를테면 관심사의 분리와 함께 응용할 수 있다.

- connection이 이루어질때마다 카운팅을 하는 요청을 생각해보자. 

그럼 커넥션이 이루어질때마다 코드를 수정해서 counter를 하고 , 다시 배포시에는 이걸 일일이 다 고쳐야 할까?! 아니다! 

- connection conter클래스를 따로 만들고, @Configuration에는 이 빈을 등록. 그리고 counter클래스의 생성자에 원래 쓰던 connection객체를 파라메터 생성자로 넘긴다.

그러면- 해당 커넥션이 맺어질떄마다관심사 분리로 counter가 1씩 증가.

실제 사용하는 커넥션 객체는 counter클래스의 생성자파라메터로 들어가있는 애가 커넥션을 수행하게 된다. !!!!

우와아아아.

1002 토비의 스프링 학습

 

- 관심사의 분리. 

- 클라이언트는 내가 어떤 오브젝트를 사용하는지에 관심이없다. 

- 생성및 관계설정의 책임을 DaoFactory에게 위임한다.

- 원래는 각각의 클래스가 가지고 있던 의존성 책임을 -> DaoFactory에게 위임하고. 각각의 클래스는 본연의 비지니스 역할(콘택스트) 에만 집중할 수 있게된다.

- 결국 이 DaoFactory가 일종의 applicationContext로서 Ioc를 담당

- 프레임워크와 라이브러리의 차이는 제어의 흐름이 누구에게 있는가이다.

- 스프링은 '시간'을 '관계'를 담당해준다.

- 각종 오브젝트들을 적절한 시간에 만들고, 그 오브젝트들의 관계를 넣어준다.

- 우리는 비지니스 로직을 공개하지 않고 코드를 짤수있게 된다. 

- 위코드 확인 : 먼저 빈들을 싱글톤으로 등록해두고 -> 클라이언트가 해당 빈을 요청하면 -> getBean으로 찾아서 리턴한다. 

<용어 정리>

- bean:

스프링이 관리하는 오브젝트. 모든 객체가 빈이 아니라, 스프링이 직접 생명주기를 관리해야만 빈이라고 부른다. 

- bean factory

: 빈의 생명주기와 관계설정을 관리하는 클래스. 보통은 빈 팩토리 클래스를 막바로 사용하기보다 어플리케이션 콘텍스트 클래스를 불러서 사용한다. 

- applicationContext :

빈 팩토리를 상속한다. 빈생명주기 + 스프링이 제공하는 부가적인 기능 .

- 직접 제작한 DaoFactory 에서 만들어낸 userDao클래스는 각각 다른 메모리값이 할당된 별개의 인스턴스이다.

반면 @Configuration어노테이션을 통해 ApplicationContext를 생성하고,

이를 통해 Bean Factory 에서 불러낸 UserDao클래스는 동일하다. 테스트 케이스 초록불을 확인할 수 있다.

즉 스프링은 기본적으로 빈을 생성할때 싱글톤 전략을 사용한다. 하지만 왜일까?

- 번외) 동일성과 동등성

동일성 : 물리적 동일성. 같은 메모리상에 위치한다. 기본적으로 Object의 equals메소드는 동일성비교를 한다. (==)

동등성 : 논리적으로 같은가. 특정기준에 의해서 같은 인스턴스임을 보장한다. 단 이때 물리적 메모리 할당값은 다를 수 있다.  (equals)

- 스프링이 싱글톤으로 빈을 생성하는 이유

: 일단 기본적인 자바 싱글톤 전략을 직접 사용한다고 했을때 발생하는 문제점이 여럿있다.

private생성자이므로 상속불가하고 , 확장불가하고, 테스트 하기 어려워진다. 밖에서 생성할수가 없으니..

그리고 서버환경에서는 반드시 한개만 만들어진다고 보장할 수도 없다. 

-> 그렇지만, 싱글톤으로 생성하는 것 적극지지 - 왜냐하면, 유저의 요청에 따라 계속해서 클래스를 생성하면 메모리가 절대로 못버텨난다. 

- 스프링은 자바의 전통적인 싱글톤 전략 대신 Ioc를 이용하여 빈을 싱글톤으로 생성하고 관리한다. 

- 싱글톤사용시 주의점

: 멀티스레드 환경에서는 객체가 공유되기 때문에 주의한다 . 

따라서 -> 상태stateless해야한다. 변경되는 상태값을 가지고 있으면 안된다.

- 변경될수있는 값은 파라메터로 혹은 지역변수로 전달한다. 이건 스택에 쌓이는 정보이므로 공유되지 않으므로 괜찮다.

- 혹은 읽기전용 변수 / 혹은 다른 싱글톤객체를 인스턴스 변수로 가지고 있는 것은 괜찮다.