일 | 월 | 화 | 수 | 목 | 금 | 토 |
---|---|---|---|---|---|---|
1 | 2 | 3 | 4 | 5 | ||
6 | 7 | 8 | 9 | 10 | 11 | 12 |
13 | 14 | 15 | 16 | 17 | 18 | 19 |
20 | 21 | 22 | 23 | 24 | 25 | 26 |
27 | 28 | 29 | 30 | 31 |
- github
- 자료구조
- 컴퓨터공학
- spring
- 뮤텍스
- 단축키
- 알고리즘
- 세마포어
- CS
- 운영체제
- IT
- 깃
- Public
- 개발
- 깃허브
- 컴퓨터과학
- 서드파티 쿠키
- 메모리
- slash 24
- java
- 소프트웨어
- 광고 기술
- 이펙티브 자바
- 자바
- 스프링
- OS
- 스터디
- 프로그래밍
- Effective Java
- package-private
- Today
- Total
목록분류 전체보기 (112)
주니어 개발자 성장기
빈 생명주기 콜백 시작 데이터베이스 커넥션 풀이나, 네트워크 소켓처럼 애플리케이션 시작 시점에 필요한 연결을 미리 해두고, 애플리케이션 종료 시점에 연결을 모두 종료하는 작업을 진행하려면 객체의 초기화와 종료 작업이 필요하다. 스프링 빈은 간단하게 다음과 같은 라이프사이클을 가진다. 객체 생성 -> 의존관계 주입 스프링 빈은 객체를 생성하고, 의존관계 주입이 다 끝난 다음에야 필요한 데이터를 사용할 수 있는 준비가 완료된다. 따라서 초기화 작업은 의존관계 주입이 모두 완료되고 난 다음에 호출해야 한다. 그런데 개발자가 의존관계 주입이 모두 완료된 시점을 어떻게 알 수 있을까? 스프링은 의존관계 주입이 완료되면 스프링 빈에게 콜백 메서드를 통해서 초기화 시점을 알려주는 다양한 기능을 제공한다. 또한 스프링..
엔티티에는 가급적 Setter를 사용하지 말자 Setter가 모두 열려있으면, 변경 포인트가 너무 많아서, 유지보수가 어렵다! 모든 연관관계는 지연로딩으로 설정! (중요) 즉시로딩 (EAGER)은 예측이 어렵고, 어떤 SQL이 실행될지 추적하기 어렵다. 특히 JPQL을 실행할 때 N+1 문제가 자주 발생한다. 실무에서 모든 연관관계는 지연로딩(LAZY)으로 설정해야 한다! 연관된 엔티티를 함께 DB에서 조회해야 하면, fetch join 또는 엔티티 그래프 기능을 사용한다. @XToOne(OneToOne, ManyToOne) 관계는 기본이 즉시 로딩이므로 직접 지연로딩으로 설정해야 한다. 컬렉션은 필드에서 초기화 하자. 컬렉션은 필드에서 바로 초기화하는 것이 안전하다. null 문제에서 안전하다. 하이버..
애노테이션 직접 만들기 @Qualifier("mainDiscountPolicy") 이렇게 문자를 적으면 컴파일 시 타입 체크가 안된다. 다음과 같은 애노테이션을 만들어서 문제를 해결할 수 있다. @Target({ElementType.FIELD, ElementType.METHOD, ElementType.PARAMETER, ElementType.TYPE, ElementType.ANNOTATION_TYPE}) @Retention(RetentionPolicy.RUNTIME) @Documented @Qualifier("mainDiscountPolicy") public @interface MainDiscountPolicy { } @Qualifier를 적용할 클래스에 적용 @Component @MainDiscount..
캐시와 조건부 요청 프록시 캐시 원서버와 직접 통신하는 경우 시간이 오래걸리기 때문에 프록시 캐시 서버를 통해서 자주 전송하는 데이터들을 캐싱해놓는다. private 캐시: 웹브라우저에서 사용하는 캐시 public 캐시: 프록시 캐시 서버에서 사용하는 공용 캐시 캐시 지시어(directives) - 기타 Cache-Control: public 응답이 public 캐시에 저장되어도 됨 Cache-Control: private 응답이 해당 사용자만을 위한 것임, private 캐시에 저장해야 함(기본 값) Cache-Control: s-maxage 프록시 캐시에만 적용되는 max-age Age: 60(HTTP 헤더) 오리진 서버에서 응답 후 프록시 캐시내에 머문 시간(초) 캐시 무효화 Cache-Contro..
캐시와 조건부 요청 캐시 기본 동작 캐시가 없을 때 데이터가 변경되지 않아도 계속 네트워크를 통해서 데이터를 다운로드 받아야 한다. 인터넷 네트워크는 하드웨어에 비해서 매우 느리고 비싸다. 브라우저 로딩속도가 느리다. -> 느린 사용자 경험 캐시 적용 응답 헤더에 'cache-control: max-age=60'와 같은 라는 캐시 제어 헤더를 넣어준다.(캐시가 유효한 시간) 응답 결과를 캐시에 저장한다. 그 후 요청부터는 캐시 유효 시간 검증을한다. 유효 시간 이내이면 캐시에서 가져온다. 시간을 초과하면 재요청을 해야 한다. 캐시 덕분에 캐시 가능 시간동안 네트워크를 사용하지 않아도 된다. 비싼 네트워크 사용량을 줄일 수 있다. 브라우저 로딩 속도가 매우 빠르다. 빠른 사용자 경험 검증 헤더와 조건부 요..
롬복과 최신 트랜드 막상 개발을 해보면, 대부분이 다 불변이고, 그래서 다음과 같이 필드에 final 키워드를 사용하게 된다. (final 키워드를 달면 생성자 호출 이후에는 변경이 불가능하다. - 상수) 하지만 생성자를 작성하는 것은 번거롭기 때문에 다음과 같은 방법을 쓴다. 생성자에 @Autowired 생략 생성자가 1개라면 생략 가능하다. 롬복의 @RequiredArgsConstructor 기능을 사용하면 final이 붙은 필드를 모아서 생성자를 자동으로 만들어준다. 위의 두 방법을 동시에 사용하면 깔끔한 코딩이 가능하다. 조회 빈이 2개 이상 - 문제 @Autowired는 타입(Type)으로 조회한다. 따라서 같은 타입의 Bean이 두 개가 있으면 오류(NoUniqueBeanDefinitionEx..