기술노트 블로그

들어가며

- 클럭

- 코어 & 멀티 코어

- 스레드 & 멀티 스레드

CPU의 속도를 빠르게 만들어보자

1. 컴퓨터 부품들은 '클럭 신호'에 맞춰 일사불란하게 움직인다.

2. CPU는 '명령어 사이클'이라는 정해진 흐름에 맞춰 명령어들을 실행한다.

-> 클럭 신호를 빠르게 반복된다면 명령어 사이클도 빠르게 반복될 것이라는 기대를 할 수 있다. 

클럭 속도

- 클럭 속도: 헤르츠(Hz) 단위로 측정

- 헤르츠(Hz) : 1초에 클럭이 반복되는 횟수

- 클럭이 "똑-딱-" 하고 1초에 한 번 반복되면 1Hz

- 클럭이 1초에 100번 반복되면 100Hz

클럭 속도를 늘리면 꼭 속도가 빨라질까? 필요 이상으로 클럭을 높이면 발열이 심각해짐

코어와 멀티 코어

- 클럭 속도를 늘리는 방법 이외에는?

- 코어 수를 늘리는 방법 ("듀얼 코어", "멀티 코어" ...)

- 스레드 수를 늘리는 방법 ("멀티 스레드" ...)

예) intel CORE - 8core, 16Thread

코어(Core) 란?

- 현대적인 관점에서 "CPU"라는 용어를 재해석 해야 함

- '명령어를 실행하는 부품'?

- 전통적으로 '명령어를 실행하는 부품'은 원칙적으로 하나만 존재

- But 오늘날 CPU에는 '명령어를 실행하는 부품'이 여러 개 존재

- '명령어를 실행하는 부품'을 코어라는 용어로 사용

코어를 두 개, 세 개, 100개 늘리면 연산 속도도 그에 비례하여 빨라지나요? 꼭 코어 수에 비례하여 증가하지는 않습니다. 조별과제를 예로 들면 4명이 한 프로젝트를 맡는다고 해서 더 빨리 프로젝트가 완료되는 것은 아니다. 코어마다 처리할 연산이 적절히 분배되지 않는다면 CPU 속도를 늘리지 못한다.

스레드란 '실행 흐름의 단위'

1코어 1스레드 CPU도 여러 소프트웨어적 스레드를 만들 수 있다.

멀티 스레드 프로세서를 실제로 설계하는 일은 매우 복잡하지만, 가장 큰 핵심은 레지스터

정해진 흐름대로 명령어를 처리해야지! 

CPU                          <-                                    메모리

인터럽트 (잠깐만!)

명령어 사이클

프로그램 속 명령어들은 일정한 주기가 반복되며 실행

이 주기를 명령어 사이클이라고 함

메모리에 저장된 명령어를 실행하려면?

cpu <-(인출)- 메모리

인출 사이클: 가장 먼저 CPU로 갖고 와야 한다

실행 사이클: 갖고 왔으면 실행해야 한다

명령어는 인출 - 실행 - 인출 - 실행 - ...

반복되면서 실행됩니다.

그런데 CPU로 명령어를 가지고 와도 바로 실행이 불가능한 경우도 있다.

메모리의 접근이 더 필요한 경우 간접 사이클이 추가될 수 있다.                      

이와 같은 정해진 흐름을 끊는 것이 바로 인터럽트이다. 방해하는 신호이다.

인터럽트

인터럽트 (interrupt) : 방해하다, 중단시키다

'CPU가 꼭 주목해야 할 때', 'CPU가 얼른 처리해야 할 다른 작업이 생겼을 때' 발생

"강대리, 이거 급한 거니까 지금 하던 일 멈추고 이것부터 처리해주게"

인터럽트 - 동기 인터럽트 (예외)

              - 비동기 인터럽트 (하드웨어 인터럽트)

"인터럽트의 종류에는 예외와 하드웨어 인터럽트가 있습니다."

대부분은 인터럽트 플래그로 인터럽트를 막을 수 있다.

DI (Dependency Injection)

- 의존성 주입

  - 한 객체가 다른 객체를 사용할 때 의존성이 있다고 함

- 런타임 시 의존 관계를 맺는 대상을 외부에서 결정하고 주입해 주는 것

- 스프링 프레임워크는 DI 기능을 지원해주는 프레임워크

DI 장점

- 의존성 주입을 인터페이스 기반으로 설계하면, 코드가 유연해짐

  - 느슨한 결합도 (loose coupling)

- 변경에 유연해짐

  - 결합도가 낮은 객체끼리는 부품을 쉽게 갈아끼울 수 있음

예를 들어 A가 직접 B에 의존하도록 하기 보다는 중간에 Interface를 두어서 결합도가 느슨해지도록 하여 변화에 영향을 덜 받게 되도록 설계를 하기도 합니다.

Runtime시 의존관계를 맺는 대상을 외부에서 결정하고 주입해 주는 것을 의미합니다.

또한 변경에 유연해지게 설계할 수 있으며 결합도가 낮은 객체 끼리는 부품을 쉽게 갈아 끼울 수 있습니다.

또한 테스트하기 좋은 코드가 될 수 있습니다.

스프링 웹 MVC 프레임워크

요청을 DispatcherServlet이 해당 요청을 받아서 HandlerMapping을 통해서 적절한 핸들러를 찾게 됩니다.

여기에서 핸들러라고 하면 컨트롤러라고 이해하시면 좀 더 이해가 쉬울 것 같습니다.

그리고 나서 핸들러 어댑터를 통해서 적절한 어댑터에서 컨트롤러를 시행합니다.

그리고 컨트롤러는 해당 리턴 값으로 뷰 네임을 리턴하게 됩니다.

그러면 DispatcherServlet이 해당 뷰 네임을 가지고 뷰 리절브를 통해서 뷰 객체를 리턴 받게 됩니다.

그런 다음에 최종적으로 뷰 렌더를 통해서 응답 값을 리턴하게 됩니다.

애노테이션 기반 MVC 프레임워크

- DispatcherServlet

- AnnotationHandlerMapping

- HandlerAdapter

- ViewResolver

프런트 컨트롤러 패턴

- 모든 요청을 단일 handler(처리기)에서 처리하도록 하는 패턴, 그렇기 때문에 중앙 집중식 요청 처리 매커니즘을 가지고 있습니다.

- 스프링 웹 MVC 프레임워크의 DispatcherServlet(프런트 컨트롤러의 역할)이 프런트 컨트롤러 패턴으로 구현돼 있음

Forward

- 서블릿에서 클라이언트(웹 브라우저)를 거치지 않고 바로 다른 서블릿(또는 JSP)에게 요청하는 방식, URL주소가 달라지지 않음

- Forward 방식은 서버 내부에서 일어나는 요청이기 때문에 HttpServletRequest, HttpServletResponse 객체가 새롭게 생성되지 않음(공유됨)

- RequestDispatcher dispatcher = request.getRequestDispatcher("포워드 할 서블릿 또는 JSP") 

dispatcher.forward(request, response)

Redirect

- 서블릿이 클라이언트(웹 브라우저)를 다시 거쳐 다른 서블릿(또는 JSP)에게 요청하는 방식

- Redirect 방식은 클라이언트로부터 새로운 요청이기 때문에 새로운 HttpServletRequest, HttpServletResponse 객체가 생성됨

- HttpServletResponse 객체의 sendRedirect() 이용

Reflection 소개

- 힙 영역에 로드돼 있는 클래스 타입의 객체를 통해 필드/메소드/생성자를 접근 제어자와 상관 없이 사용할 수 있도록 지원하는 API (class.class, instance.getclass, class.fullname)

- 컴파일 시점이 아닌 런타임 시점에 동적으로 특정 클래스의 정보를 추출해낼 수 있는 프로그래밍 기법이기도 합니다.

- 주로 프레임워크 또는 라이브러리 개발 시 사용됨

사용법 링크 : https://www.baeldung.com/reflections-library

* 참고로 jvm의 클래스 로더는 클래스 파일에 대한 로딩이 끝나면 클래스 타입의 객체를 생성해서 메모리 힙 영역에 저장합니다.

Reflection 사용하는 프레임워크/라이브러리 소개

- Spring 프레임워크 (ex. DI)

- Test 프레임워크 (ex. JUnit)

- JSON Serialization/Deserialization 라이브러리 (ex. Jackson)

- 등등

실습

- @Controller 애노테이션이 설정돼 있는 모든 클래스를 찾아서 출력한다.