자바 메모리 구조

• stack, method( c로 치면 data + static ), heap
• method영역은 실행시점에 소스코드나 static변수들이 할당
• heap영역은 런타임에 생성된 인스턴스 변수들이 할당
• stack영역은 함수가 호출될때 지역변수나 매개변수들이 메모리에 할당

람다식을 사용하는 이유는 1회용 익명 메소드가 필요하기 때문 > 하지만 자바는 독립적인 메소드만을 생성하지 못하기 때문에 익명객체를 이용해서 만든다.
메서드를 하나의 식(expression)으로 표현한 것
메서드를 람다식으로 표현하면 메서드의 이름과 반환값이 없어지므로 람다식을 익명함수(anonymous function)라고도 한다.

람다식 만드는 방법
메서드에서 이름과 반환타입 제거 매개변수 선언부와 몸통{} 사이에 -> 추가 //기존 반환타입 메서드이름 (매개변수 선언) { ... }

//람다식 (매개변수 선언) -> { ... } 반환값이 있는 메서드는 return 대신 식(expression)으로 대신할 수 있다.(연산 결과가 자동으로 반환값이 되고 ; 생략) 매개변수의 타입은 추론가능하면 생략 가능 (대부분 생략 가능) 두 매개변수 중 하나의 타입만 생략하는 것은 불가능 매개변수가 하나뿐이면 괄호() 생략 가능 중괄호{} 안의 문장이 하나일 때는 중괄호{} 생략 가능 (문장 끝에 ; 생략) 중괄호{} 안의 문장이 return문일경우 중괄호{} 생략 불가능 //기존 int max(int a, int b) { return a > b ? a : b; }

//람다식 (int a, int b) -> { return a > b ? a : b; }

//return문 대신 expression 사용 (int a, int b) -> a > b ? a: b

//매개변수 타입 생략 (a, b) -> a > b ? a : b

//매개변수 1개일 경우 괄호 생략 a -> aa //OK int a -> aa //에러

//본문 문장 1개일 경우 중괄호 생략 (String name, int i) -> System.out.println(name+"="+i)

Exception처리코드 여부를 compiler가 check

• 없으면 컴파일 에러!!

=> 프로그램 실행 흐름상 예외 발생 가능성있는 상황을 표현.(로직상 나올 수 있는 상황)

=> Code상의 문제가 아니라, 실행상황에 따라 발생가능성 있는 예외.

=> 프로그램 구현 흐름상 발생할 수 있는 예외.

먼저, RuntimeException을 살펴보자.

RuntimeException은 다시말하면, Unchecked Exception이라고 말할 수 있는데, 발생할 것 같은 예외를 체크해주지 않아서

(즉, 프로그래머의 실수로인해서) 발생하는 실수이기 때문이다.

=> Code를 잘못 만들어서 생기는 문제.

=> 업무의 흐름보다는 core(기본)적인 부분의 에러.

=> 컴파일 하는데는 문제가 없다. 실행하면 문제가 발생함.

@Component는 스프링이 관리하는 컴포넌트를 나타내는 일반적인 스테레오 타입이다.
또한 Spring(IOC) Container에 Bean을 등록하도록 메타데이터를 기입하는 어노테이션이다.
설정 클래스에 @ComponentScan을 붙여주면 @Component가 붙은 클래스들을 탐색해 빈으로 등록을 해준다.
scan-auto-detection과 dependency injection을 사용하기 위해서 사용되는 가장 기본 어노테이션이다.
좀더 세부적인 유스 케이들을 위하여 @Component의 구체화된 형태로 @Repository, @Service, @Controller들이 있다.

context:component-scan는 @Component 만 검색하며 일반적으로
@Controller, @Service, @Repository를 찾지 않는다.
하지만 @Component로 주석이 붙어 있기 때문에 스캔된다!!!
ex)

@Component
public @interface Service {  
    ….  
}  

@Controller : Presentation Layer(클라이언트와의 접점이며 데이터의 입출력이 일어남)에서 Contoller를 명시하기 위해서 사용
=> @RequestMapping 어노테이션을 해당 어노테이션 밑에서만 사용할 수 있다.

@Repository : Persistence Layer(DB에 직접적으로 접근하는 계층)에서 DAO를 명시하기 위해서 사용
=> 플랫폼 별 예외를 잡아서 Spring의 통합 검사되지 않은 예외 중 하나로 다시 던진다.

@Service : Business Layer(컨트롤러와 뷰를 연결)에서 Service를 명시하기 위해서 사용 => @Component와 별 차이가 없지만 추후에 스프링에서 추가 예외처리를 업데이트할 수 있기 때문에 비즈니스 로직에 붙여준다.

@Component : 그 외에 자동으로 스캔해서 등록하고 싶은 것들을 위해 사용

컴포넌트 클래스들에 @Component를 붙일 수도 있지만,
@Repository, @Service, @Controller를 붙인다면 도구들이 클래스들을 처리하는데 더 적합하도록 할 수 있고
구체적으로 사용하면 어떤 부분에 쓰이는지 시각적으로 판단하기 편하다. 또한, 관점(aspects)에 더 연관성을 부여할 수 있다. - AOP를 통한 처리가 쉽게 가능하다.

스프링 MVC의 주요 구성 요소

• DispatcherServlet : 클라이언트의 요청을 전달 받는다. 컨트롤러에게 클라이언트의 요청을 전달하고, 컨트롤러가 리턴한 결과 값을
  View에 전달하여 알맞은 응답을 생성하도록 함(스프링 제공)
• HandlerMapping : 클라이언트의 요청 URL을 어떤 컨트롤러가 처리할지를 결정(스프링 제공)
• Controller : 클라이언트의 요청을 처리한 뒤, 그 결과를 DispatcherServlet에 알려 준다.(실제 로직을 담당)
• ModelAndView : 컨트롤러가 처리한 결과 정보 및 뷰 선택에 필요한 정보를 담는다.
• ViewResolver : 컨트롤러의 처리 결과를 생성할 뷰를 결정(스프링 제공)
• View : 컨트롤러의 처리 결과 화면을 생성

1. 클라이언트의 요청이 DispatcherServlet에 전달
2. DispatcherServlet은 HandlerMapping을 사용하여 클라이언트의 요청을 처리할 컨트롤러 객체를 구함
3. DispatcherServlet은 컨트롤러 객체의 handleRequest() 메서드를 호출하여 클라이언트의 요청을 처리
4. 컨트롤러의 handlerRequest() 메서드는 처리 결과 정보를 담은 ModelAndView 객체를 리턴
5. DispatcherServlet은 ViewResolver로부터 응답 결과를 생성할 뷰 객체를 구함
6. 뷰는 클라이언트에 전송할 응답을 생성

스프링 MVC에서 모든 요청의 흐름을 관리하는건 DispatcherServlet
** DispatcherServlet은 전달받은 설정 파일을 이용해서 스프링 컨테이너를 생성한다.

1 단계 : DispatcherServlet 설정 및 스프링 컨텍스트 설정

자바 웹 어플리케이션의 설정 파일인 web.xml에 다음의 정보를 추가

• 클라이언트의 요청을 전달받을 DispatcherServlet 설정
• 공통으로 사용할 어플리케이션 컨텍스트 설정 DispatcherServlet의 설정은 웹 어플리케이션의 /WEB-INF/web.xml파일에 추가하면 됨.

2 단계 : 설정 파일에 HandlerMapping 설정 추가 HandlerMapping은 클라이언트의 요청을 어떤 Controller가 처리할지에 대한 정보를 제공

3 단계 : Controller 구현 및 설정 스프링에서 제공하는 Controller 인터페이스를 구현하면 됨(다양한 Controller 인터페이스를 제공)

4 단계 : 설정 파일에 ViewResolver 설정 추가 Controller가 리턴하는 ModelAndView는 뷰 정보를 담고 있음.

5 단계 : 뷰 코드 구현 JSP와 같은 웹 어플리케이션 자원을 이용하여 뷰를 생성

@Retention(RetentionPolicy.RUNTIME)
@Import(DelegatingWebMvcConfiguration.class)
@Target(ElementType.TYPE)
public @interface EnableWebMvc {
}

어노테이션 기반 Spring MVC를 사용할때 편리한 웹 MVC 기본 설정 방법
@Enable로 시작하는 어노테이션은 자바 설정에서 편의를 제공하기 위해서 도입되었다.
@EnableWebMvc 어노테이션을 적용시키면 대부분 Spring Web에 필요한 빈들은 자동으로 설정 해준다.
WebMvcConfigurationSupport 에서 구성한 스프링 MVC구성을 불러온다.
=> WebMvcConfigurationSupport MVC 자바 설정에서 기본 설정을 제공하는 메인 클래스이다. 주로 @EnableWebMvc를 통해서 임포트된다.
(더 정확히 말하면 이 클래스를 상속한 DelegatingWebMvcConfiguration가 임포트된다.)
커스터마이징이 필요하다면 WebMvcConfigurationSupport 클래스를 상속해서 필요한 메소드를 오버라이딩 해도된다.

DispatcherServlet가 스프링 컨테이너를 생성하기 위해선 입력으로 받는 설정 클래스에는
HandlerMapping 빈과 HandlerAdapter 빈이 등록되어있어야 한다.
하지만 설정 클래스에 @EnableWebMvc 애노테이션을 추가해주면 해당 빈을 자동으로 추가 해준다.

밑의 두 클래스를 포함하기 때문이다!!

o.s.w.servlet.mvc.method.annotation.RequestMappingHandlerMapping. 
o.s.w.servlet.mvc.method.annotation.RequestMappingHandlerAdapter. 

Spring Java Config 설정
Spring MVC 설정
무엇을 설정하는가? => MVC와 관련된 설정들.

1.HandlerMapping
2.HandlerAdapter
3.ViewResolver에 관련된 설정을 진행한다.
많은 설정을 해야하지만 @EnableWebMvc 어노테이션을 적용시키면 대부분 Spring Web에 필요한 빈들은 자동으로 설정 해준다.

나머지, 추가적인 설정을 해야한다면 spring 5 버전부터 WebMvcConfigurer 가상 객체 상속시켜 오버라이딩 하여 고쳐나가면 된다. ==> WebMvcConfigurer WebMvcConfigurer 인터페이스는 MVC 네임스페이스를 이용한 설정과 동일한 설정을 하는데 필요한 메소드를 정의하고 있다.
Spring MVC를 자바 기반으로 설정할 때 사용한다.
ex) HttpMessageConverter를 추가할 때 WebMvcConfigurer 인터페이스를 상속한
@Configuration 클래스를 만들고, configureMessageConverters 메소드를 구현해주면 된다.

if) 스프링 MVC를 완벽하게 제어하고 싶다면 -> @Configuration + @EnableWebMvc

HeapDump는 Memory 누수를 진단하는데 중요한 역할을 하는 TroubleShooting 방법입니다.
ThreadDump에서 확인한 Application의 상세 Stack을 확인할 수 있는 장애 진단에 매우 중요한 부분이라 볼수 있습니다.

Heap이란 Java에서 사용하는 object들을 저장하는 공간입니다.

Heap에는 java object 정보만 저장되는 것이 아니고 메타 정보 및 각 object들에 대한 참조 정보도 담겨 있습니다. Heap 메모리에 존재하는 모든 object는 Root 노드부터 시작해서 parent/child 형식의 tree 구조를 형성하고 있습니다. 이러한 tree 구조는 각 object들의 참조 정보를 통해 이루어집니다. tree 구조가 꼭 정형화된 top/down 방식의 구조로만 이루어지지 않고 간혹 역 참조에 의해 상호 참조가 발생하기도 합니다.

Heap의 정보를 분석하는 것은 java에서의 메모리 문제(각종 OutOfMemoryError 문제들)를 해결하기 위한 중요한 작업입니다.

Heap dump 생성 방법 1.HPROF 옵션과 함께 JVM을 기동한 경우
2.HeapDumpOnOutOfMemoryError 옵션과 함께 JVM을 기동한 경우
3.HeapDumpOnCtrlBreak 옵션과 함께 JVM을 기동한 경우

===> heap dump 튜닝?? ==> heap dump 는 jvm 성능을 높이기 위한 방법??

레디스(Redis)는 Remote Dictionary Server의 약자로서 ‘키-값’ 구조의 비관계형 데이터를 저장하고 관리하기 위한 NoSQL의 일종이다.

• 애플리케이션이 호출하는 데이터베이스 쿼리 결괏값을 데이터베이스 앞단에서 인메모리 캐시

• Pub/Sub 구조의 메시지 브로커 혹은 리스트 데이터 구조를 사용한 메시지 큐, 대기열

• 사용자 인증 토큰, 세션 상태 등 세션 정보를 관리하는 세션 스토어

이 중에서 가장 강력한 기능은 인메모리 캐시(In-Memory Cache)입니다.
실제로 Redis를 사용하는 대부분의 개발팀은 이 기능을 사용합니다.
데이터베이스 쿼리 결괏값을 메모리에 저장하였다가 애플리케이션에 전달해주고, 결괏값이 캐싱에 없는 쿼리의 경우는 데이터베이스에서 결과를 가져와서 애플리케이션에 전달 후 캐시 합니다.

Cache? 한번 읽은(처리한) 데이타를 임시로 저장하고 필요에 따라 전송,갱신,삭제하는 기술로 보통은 데이타의 보관장소로 서버의 메모리를 사용하는 경우가 많다
그렇기 때문에 디스크에서 정보를 얻어오는 것보다 훨씬 빠른 I/O성능을 얻을 수 있으나 서버가 다운되거나 재부팅되는 경우 사라지는 성격의 휘발성을 가지고 있어
영속적으로 보관할 수 없는, 말 그대로 임시적으로 보관하고 빠르게 그 정보에 접근하기 위한 용도로 사용해야 한다.

(물론 정보의 성격에 따라 별도의 디스크백업 및 TTL등의 설정으로 영구보관이나 오랜기간 유지가 가능하다. 단 이런 설정들이 꼭 필요하다면 Cache를 적용하는게 맞는지 한 번도 타당성을 검토해 보는게 좋겠다)

서버간 불필요한 트래픽을 줄일 수 있고,
그로 인해 웹어플리케이션 서버의 부하 감소시키고,
어플리케이션의 빠른 처리성능(조회)을 확보해서 궁극적으로 어플리케이션를 사용하는 고객에게 쾌적한 서비스경험을 제공하는 것이다.

추상화된 API와 어노테이션을 제공
어노테이션 사용만으로 일반 Service 메서드를 캐시 함수로 사용 가능
SpringBoot의 Auto Configuration 적용으로 Cache서버 설정이 간결
Springboot Starter Kit을 기본으로 제공함 spring-boot-starter-data-redis

• 스프링부트 의존성 라이브러리 추가
  Redis CacheServer설정
  의존성 라이브러리 추가 (Maven기준) — pom.xml에 추가

• Redis 커넥션 정보 설정 Redis 서버설정 — application.yml or application.properties 파일에 추가
  spring.cache.type=redis
  spring.redis.host=localhost
  spring.redis.port=6379

• SpringBoot 메인클래스에 ‘캐시사용' 알려주기 SpringBoot에 캐시사용하겠다고 알려주기 — Springboot Main Application Class에 @EnableCaching 어노테이션 추가
  @EnableCaching
  @SpringBootApplication
  public class RedisCacheApplication {
  public static void main(String[] args) {
  SpringApplication.run(RedisCacheApplication.class, args);
  }
  }

• 사용할 Method ( controller 메서드 or service 메서드)에 어노테이션 달아주기 -> 캐시전략에서 정해진 ‘서비스&정보’ 사용할 서비스 메서드에 어노테이션 달아주기
  주요 어노테이션
  @Cacheable @CachePut -> 캐시등록
  @Cacheble은 캐시가 있으면 캐시의 정보를 가져오고, 없으면 등록한다.
  @CacehPut은 무조건 캐시에 저장한다.
  @CacheEvict -> 캐시삭제
  이렇게 해 주면 우리가 Cache가 필요한 API나 서비스 메서드에 어노테이션을 붙여서 바로 사용할 수 있다.

SSL(Secure Sockets Layer)은 Certificate Authority(CA)라 불리는 서드 파티로부터 서버와 클라이언트의 인증을 하는데 사용된다.
주로 전송계층과 응용계층 사이에서 보안조치를 하는데 사용하게 된다.
우리들이 많이 접하게 되는 HTTPS://는 SSL을 사용하는 경우를 의미한다.

client Hello: client에서 SSL버전 정보와 지원하는 암호화 방식, 무작위 바이트 문자열(이후에 사용하게 되는 중요한 데이터입니다)이 포함 되어 전달 됩니다. 이미 SSL handshake를 했었다면 세션을 재사용 할 수 있습니다.
server Hello: 지원하는 암호화 방식 중 서버에서 어떤것을 사용할 지, 세션 ID, 서버측에서 생성한 무작위 바이트 문자열을 전송합니다. 클라이언트에서 인증서를 요구하게 되면 SSL 인증서를 전송하게 됩니다.
인증서를 받게 되면 위에서 언급했던 방식(인증서가 서버가 신뢰할 수 있는지 어떻게 판단할까?)로 신뢰할 수 있는 사이트 인지 판단하게 됩니다.이 과정을 통해 클라이언트는 공개키를 얻게 됩니다.
이후 클라이언트는 자신이 만든 무작위 바이트 문자열과 서버쪽에서 전송된 무작위 바이트 문자열을 조합하여 pre master secret키를 생성합니다. 이 키는 이후 데이터를 주고 받을 때 대칭키 방식을 사용할 때 사용하게 됩니다. 이 pre master secret키를 서버로 전송할 때 인증서에서 받았던 키를 이용하여 공개키 방식 암호화를 하게 됩니다. 그리고 서버쪽으로 전송하게 됩니다.
서버쪽에서는 수신한 pre master secret키를 비밀키를 이용하여 복호화 하여 얻게된다.
server client 둘 다 일련의 과정을 거쳐 pre master secret키를 master key로 만들게 되고 이 master key를 이용하여 session key를 만들게 된다.
이후 데이터를 주고 받을 떄 session key를 대칭키 방식으로 이용하여 통신하게 됩니다.
통신이 끝나면 세션키를 폐기합니다.