정의 스프링이 제어권을 가지고 직접 만들고 관계를 부여하는 오브젝트 즉 Ioc / DI 컨테이너가 관리하는 자바 객체 스프링 컨테이너는 빈의 생존 기간도 관리하며, 빈의 생존기간을 빈 스코프(Bean Scope)라고 정의함 빈 스코프 (Bean Scope) 종류 설명 singleton 컨테이너를 기동할 때 하나의 빈 인스턴스가 만들어지고, 이 후부터 해당 인스턴스를 공유하는 방식, 기본 스코프 prototype 컨테이너에 빈을 요청할 때마다 새로운 빈 인스턴스가 만들어짐, 멀티 스레드 환겨에서 오동작이 발생하지 말아야 하는 빈일 경우 사용 request HTTP 요청이 들어얼 때마다 새로운 빈 인스턴스가 만들어짐, 웹 어플리케이션 만들 때만 사용 가능 session HTTP 세션이 만들어질 때마다 새로운..

정의 인스턴스의 생명주기를 관리 생성된 인스턴스들에게 추가적인 기능을 제공 SPRING에서 컨테이너(DI / IOC 컨테이너)로 인스턴스 관리시 장점 인스턴스의 스코프를 제어할 수 있음 인스턴스의 생명주기를 제어할 수 있음 AOP방식으로 공통기능을 집어 넣을 수 있음 의존한느 컴포넌트 간의 결합도를 낮춰서 단위테스트를 쉽게 만듬 SPRING에서 제공하는 컨테이너 BeanFactory : IoC / DI에 대한 기본기능을 가지고 있음 ApplicationContext : BeanFactory의 모든 기능을 포함하며, 일반적으로 BeanFactory보다 추천됨 트랜잭션처리, AOP 등에 대한 처리를 할 수 있음, BeanPostProcessor, BeanFactoryPostProcessor 등을 자동으로 등..

GC종류를 명확하게 설명을 못해서 정리 GC종류 Serial GC Parallel GC CMS GC G1 GC Serial GC -XX:+UseSerialGC 32비트 JVM에서 돌아가는 싱글쓰레드 어플리케이션에서 사용 MinorGC, MajorGC 모두 순차적으로 수행 (싱글쓰레드 방식) Deletion and Compacting 수행 Parallel GC (Throughput Collector) -XX:+UseParallelGC 64비트 JVM에서 돌아가는 멀티 CPU, 유닉스 머신에서 사용 Default로 young generation에서만 멀티스레드를 활용, 옵션을 통해 old generation에서도 멀티스레딩 활용 가능 많은 CPU를 사용하기 때문에 GC의 부하를 줄이고, 애플리케이션 처리량을..

정의 상태를 객체화하여 상태가 행동을 할 수 있도록 위임하는 패턴 상태 클래스들을 인터페이스로 캡슐화 하여, 인터페이스를 호출하는 방식 사용하는 경우 객체 동작이 상태에 의존하는 경우 오브젝트 상태에 따라 여러 부분의 조건문이 있는 경우 예시 /* 캡슐화 인터페이스 정의 */ public interface MonitorState { public void checkState(); } /* 상태클래스 정의 */ public class Normal implements MonitorState { @Override public void checkState() { System.out.println("정상상태 확인"); } } /* 상태클래스 정의 */ public class Warning implements Mon..

쿠키 / 세션을 사용하는 이유 HTTP 프로토콜의 무상태성, 비연결성과 같은 특징 으로 모든 요청간 의존관계가 없음, 즉 현재 접속한 사용자가 이전에 접속했던 사용자인지 알 수 있는 방법이 없음 계속해서 연결을 유지하지 않기 때문에 리소스 낭비가 줄어드는 것은 장점이지만, 통신할때마다 클라이언트는 매번 인증을 해야하는 단점으로 인하여 이전 요청과 현재요청이 같은 사용자 요청인지 알기 위해 상태를 유지하기 위해서 쿠키와 세션을 사용함 쿠키 쿠키 정의 클라이언트(브라우저) 로컬에 키와 값이 들어있는 데이터 파일 (저장형식 텍스트) 사용자 인증이 유효한 시간을 명시 가능, 유효 시간이 정해지면 브라우저가 종료되어도 인증이 유지 사용자가 따로 요청하지 않아도 브라우저가 Request시에 Request Heade..

연관관계 매핑 구성 방향 : 단방향 / 양방향이 있음, 방향은 객체관계에서만 존재함, 테이블 관계같은 경우 항상 양방향 다중성 : 다대일, 일대다, 일대일, 다대다와 같은 다중성이 존재 연관관계의 주인 : 객체를 양방향 관계로 만들시, 주인을 지정해야함 연관관계는 객체들의 협력 공동체를 만들기 위하여 필요함, JPA에서 가장 중요한 것은 객체와 테이블을 어떻게 매핑되는지 이해하는 것이므로 연관관계는 중요함 테이블 중심의 설계의 문제 객체를 테이블에 맞추어서 모델링할 경우, 협력관계를 만드릭가 어려움 테이블은 외래키로 조인을 사용하여, 연관된 테이블을 찾고, 객체는 참조를 사용하여 연관된 객체를 찾음 테이블과 객체사이의 이러한 차이로 인한 제약조건이 생김 단방향 연관관계 객체 연관관계 회원 객체는 Memb..

SPL 쿼리시 SQL로 쿼링할 때처럼 잘안되서, 해당 부분 정리 참고 https://docs.splunk.com/Documentation/Splunk/7.3.2/SearchReference/SQLtoSplunk (Splunk docs 참고) 비교 SQL command SQl example SPL example SELECT * SELECT * FROM mytable source=mytable WHERE SELECT * FROM mytable WHERE mycolumn=5 source=mytable mycolumn=5 SELECT SELECT mycolumn1, mycolumn2 FROM mytable source=mytable | FIELDS mycolumn1, mycolumn2 AND/OR SELECT ..

의존성 개념 객체간의 관계를 뜻함, 의존관계 주입 개념 외부에서 객체를 생성해서 넣어주는 것 정의 필요한 객체를 setter나 constructor로 전달 받아서 넣어주는 것 일반적으로 의존성 주입은 SPRING에서 많이 사용되며, 주입방법도 여러가지가 있음 의존성 주입 방법 필드 주입 수정자 주입 생성자 주입 일반적으로 익숙한건 @Autorwired를 통한 필드 주입이 익숙할 듯 (필자는 생성자 주입을 선호함) 필드 주입 @Service public class UserService { @Autowired private UserRepository userRepository } 주입방법중 가장 간단함, 간단해서 막 추가가능(장점이라보기 어려움), 주입 필드를 Final로 정의 불가 수정자 주입 @Servi..

확인 사항 CPU -> 메모리 -> 디스크 -> 네트워크 순으로 확인 자원 모니터링은 5초 혹은 10초 간격으로 확인 자원 사용률은 프로세스랑 연관하여 분석 CPU CPU 자원은 부족여부 CPU 사용 유형중 시스템이나 IO wait의 사용률 확인 (높은지 확인해야함) 프로세스별 CPU 사용률 분포가 균등한지 확인 실행큐에 얼마나 쌓였는지 확인 메모리 메모리가 부족 (SWAP 발생 여부) 서버 전체 또는 개별 프로세스 단위로 메모리 사용량이 지속 증가하는지 확인 파일 캐시 영역으로 사용하는 메모리량 확인 디스크 디스크 서비스 기간 확인 (디스크 대기시간을 포함한 시간 확인) 특정 디스크로 입출력이 집중했는지 확인 파일 시스템 중 공간 부족 한 곳 확인 디스크 스프라이트가 잘 구성되어있는지 확인 스토리지 채..