1. 왜 파일을 업로드 할때 바로 inputStream으로 처리하지 않고, transferTo같은 메소드를 통해서 한번 임시파일로 저장해둔 후에 다시 해당 파일을 처리로직을 짜야 하는지 궁금했다.
-> 이유:
곧바로 웹 애플리케이션이 동작하고있는 중인 JVM메모리상에 곧바로 파일을 로드해버리면, 대용량파일일 경우 굉장한 부담이 될수있기 때문이다. 그렇기 때문에 일단 임시파일로서 업로드하고 처리한다!
2. system.out.println을 통해 로그를 찍으면 안좋은 이유
1) 로그에 필요한 필수적인 추적정보들이 누락되며 개발자가 어떤식으로 작성하느냐에 따라서 형식이 무분별하게 된다( ex, 어떤클래스?몇시 ? 등등)
2) log파일에 쓰여지지 않고 콘솔에 출력되기 때문에 통합적인 관리가 어렵다
3) native I/O로서 synchronized키워드를 사용한다. 성능면에서 훨씬 안좋다고 한다.
빈을 가져오는 방법
1. ApplicationContext에서 직접 getBean하기 -> 로우레벨의 기술(나는 스프링을 사용중이다!~) 라는 것을 들켜버리므로 좋지 않다.
2. Factory클래스를 만들기
- ObjectFactoryCreatingFactoryBean을 @Bean으로 올린다.
인터페이스가 있고 - 이 인터페이스를 구현한 ObjectFactoryCreatingFactoryBean이 있음. 해당 클래스의 메소드 setTargetName 이름을 넣어주고 빈으로 등록해서 올린다. 사용할때는 인터페이스 타입으로 @Autowired받으면 됨. 다만 스프링이 정의해둔 인터페이스를 가져다 쓴다는 것이 찜찜할 수 있다.
어쨌든 그래도 로우레벨을( 어플리케이션콘텍스트) 한번감싸서 팩토리 빈으로 빈을 생성해 주기때문에- 1번보다는 낫다. 빈이 어떤식으로 생성되는지는 몰라도 되기 땜에.
3. Provider<T> 인터페이스 이용하기
해당 인터페이스를 구현한 클래스를 @Bean으로 올리면 됨. Provider<돌려줄 빈타입> 으로 @Autowired받아서사용.
- 재미있었던점!!
첨에 @Configuration으로 안올리고 일반 @Component로 한뒤에 new SingletonScopeBean으로 되돌려주도록 메소드 만들었더니 해당 빈또한 @Component로 돌렸음에도 불구하고 새로운 빈이 또 생겨나서 싱글톤이 아니게되었다!!
그래서 @Autowired로 바꾼뒤에 돌려주게 만들었더니 이제 싱글톤빈으로 돌려줌. 그래서 @보통은 @Configuration으로 붙인담에 그런식으루 쓰는구나 싶었다.. 헷갈리니까?
대신에 사용할수있는 방법은 - static final로 클래스가 로딩될때 미리 메모리에 올려두고 공유하게 하는 것이다. Pattern.compile을 사용하면 된다!
같은 조건에서 100번 돌린결과
설령 해당 메소드로 직접불렀다고 하더라도!! 싱글톤임을 보장해준다. @Configuraiton자체도 그자체로 빈이 된다.
[스프링]
- 메타 정보 파일 + 클래스 => 스프링 어플리케이션
1. 메타정보파일 : xml, 자바 config , db데이터 등등 다양. resourceLoader만 필요적절하게 있다면뭐든 형식오케이
- 스프링 빈 등록방법
1. 형식 : xml또는 java config
2. 방법 :
1) 직접 bean id일일이 등록
2) component scan해서 베이스 패키지 등록 - 아래에 있는 애들 다 등록하기 . 빈스캐너 등록
3) 스테레오 타입 어노테이션 이용 (위에랑 합쳐서,할수있음)
4) 빈스캐너 : 직접 등록하기 or 해당 빈스캐너를 이미 디폴트로 들고있는 applicationcontext사용하기(우리는 보통 이쪾을 사용하니까 걍 스테레오 타입어노테이션 막붙여버리고 ㅇㅇ 아무렇지않게 쓰고있었다)
3. 반드시 필요한것 : id , class 보통 어노테이션 방식쓰면 - id는 class명에서 앞에만 소문자로 따서 ㅇㅇ만들어짐
4. 빈 스코프설정 : 디폴트 싱글톤. 특별한 경우 prototype으로 계속 생성도 가능
5. @configuration : 이거 이용해서 여러빈을 한번에 등록. 얘 자체도 하나의 빈이기때문에 싱글톤. 설령 얘의 메소드를 직접부른다고 하더라도1!! 반환된 객체는 싱글톤이다 (오묘~~~@!)
6. 같은 타입의빈이 여러개 있을떄 ? -.> @qualified같이 이름으로 구분하거나 / 아니면 배열로 주고 파라메터 받아서 적절하게 반환한다는 전략도 있음. HashMap으로 해서 이름/ 객체로 받을수도 있음!!! 개쩐당
- DI하기
1. 전략 : setter / 생성자 / 필드 / 일반 메소드 주입
2 . 만약에 테스트 환경같이 갈아끼울필요있으면 setter주입고려해보고.
3. 생성자주입쓰면 한번에 할수있으니까 편하다-
-스테레오타입어노테이션
: 해당 어노테이션으로 빈등록하면 - aop쓸때 걸러낸다던지. 좀더 명확하게 클래스에 이런애입니다!! 라고 정보를 모아서 볼수있으니 편함. 이용하자. @Repository, @Controller, @Service 그외에 애매한 애들은 @Component라고 등록.
- @Configuration에 등록하는 애들 : 개발자가 작성한 클래스가 아니라 기술적으로 필요한 애들등록할때도 사용@Bean으로.
- 다양한 종류의 ApplicationContext가 있다. 여기는 빈들이 생성(초기화) 되고 . 한번 호출해준다!! 그러면- 이제 타고타고 유저요청에따라 main메소드가 실행되고.
1. 스프링은 빈 객체를 싱글톤전략으로 (기본적으로는) 사용한다.
2. 왜냐? 유저 요청이 들어올때마다 컨트롤러 서비스 각각 개별적으로 띄우면- 금방 메모리가 바닥날것이기 때문에 같은 빈을 공유하는 것이 효율적이다.
3. 여기서 의문!! 그럼 아니 어떻게 하나의 컨트롤러가 유저요청을 다받아내??
4. 톰캣은 기본적으로 max스레드 수가 200으로 되어있으니까 최대 동시에 200요청을 하나의 컨트롤러가 받아낸다고 ?!! 하는 의문이 들어서 찾아보았다---
https://jeong-pro.tistory.com/204
<< 여기 글을 보고 의문을 해결할수있었다!!!
5. 결론 - 객체 주소(heap영역_)는 공유하지만, 메소드(stack영역)는 개개별 스레드마다 생성되므로- 동기화 우려가 없다. 그래서 빈 객체는 무상태로 유지해야하는 것이 중요하다! 그래야 동기화 이슈가 없다-. 그리고 메소드는stack별로 유저마다 다른 값을 가질것이므로 - 컨트롤러라는 객체를 '공유'한다는 것이 가능하다.
6. '공유'라는 개념을 헷갈리고 있었던것이당.
7. 커넥션풀과 톰캣스레드 수는다르다!!
-> 톰캣스레드별로 커넥션을 물고간다? 뭐 그런 식의 표현을 읽은적이 있다... 근데 커넥션 수 100개만 넘어가도 뻑 죽던데 왜지... 하는 의문이 있었는데그것도 해결!!
스레드를 공유하는게 아니라 객체의 수를 공유한다는 것이었땅.
# 리눅스 명령어 정리
## su
switch user
- su: root로 변경
- su [유저명] : 해당 유저로 변경
## sudo
- superuser do
- etc/sudoers파일에서 sudo 명령어실행가능한 유저들 수정가능
- 루트 권한으로 명령어 실행
## dmesg
- 부팅하는 동안의 로그메시지 출력 명령어
- etc/log/dmesg에 쌓인다고함
## service, systemctl
- 서비스 제어 명령어
- systemctl 옵션 서비스명.service~ (.service는 생략가능)
- 예시
$ systemctl start iptables
- CentOS 6이전 버전은 service~구문으로,
systemctl을 사용해달라는 친절한 메시지를 확인할수있음
- 원래는 /etc/init.d에 등록된 서비스들을 제어하는명령어이나 현재는
systemctl list-unit-files명령어를 통해서 확인가능하다.
## shutdown
- 시스템 종료명령어. 아주 큰일나니까(맘대로 서버 종료!ㅎ..) 쓰지말고 로그아웃을 합시다.
## reboot
- 시스템 재시작명령어.
shutdown -r을 통해서도 할수있음
