3주차 정리 [인프런 워밍업 클럽 0기 BE]

kkjim1324 1달 전

3주차는 프로젝트 나머지를 진행하려고 했는데 시간이 너무 바빠 그동안 미뤘던 JAVA, Spring 개념 공부를 좀 더 하려고 한다.

JAVA

JVM

운영체제 종속받지 않고 자바를 실행시켜주는 가상 컴퓨터

  • 이전에 C 개발 했을 때 윈도우랑 리눅스 돌아가는거 따로 구현함

Java compiler

.java(고수준언어 - 사람이 읽는 언어) -> .class(저수준언어) 로 변환시켜주는 프로그램
JDK설치했을때 bin 안에 javac.exe 파일
.class는 기계어는 아님(바이트코드) 그래서 JVM이 기계어로 읽을 수 있도록 해석해줌
바이트 코드는 다시 실시간 번역기 또는 JIT 컴파일러에 의해 바이너리 코드로 변환

GC

가비지 컬렉션
유효하지 않은 메모리를 JVM의 가비지 컬렉터가 불필요한 메모리를 알아러 정리

  • C에서는 메모리 해제를 직접 해줘야했는데 이 부분이 너무 어려웠음

아래 내용은 따로 가져옴

JVM의 Heap영역은 처음 설계될 때 다음의 2가지를 전제(Weak Generational Hypothesis)로 설계되었다.
대부분의 객체는 금방 접근 불가능한 상태(Unreachable)가 된다.
오래된 객체에서 새로운 객체로의 참조는 아주 적게 존재한다.
즉, 객체는 대부분 일회성되며, 메모리에 오랫동안 남아있는 경우는 드물다는 것이다. 
그렇기 때문에 객체의 생존 기간에 따라 물리적인 Heap 영역을 나누게 되었고 Young, Old 2가지 영역으로 설계되었다. 
초기에는 Perm 영역이 존재하였지만 Java8부터 제거되었다.
출처: https://mangkyu.tistory.com/118

JAVA 메모리 구조

런타임 데이터 영역 5가지 존재

  • 메소드영역

  • 힙 영역

  • 스택 영역

  • PC 레지스터

  • Native Method Stack

자바 프로그램을 실행하면 JVM은 OS로 부터 메모리를 할당받음
JVM의 메모리 영역은 3가지
스태틱(메소드) 영역 - Class , Static 변수, 생성자, 메소드 같은 것들을 저장. 종료시 해제
힙 영역 - 참조형 데이터 저장되는 공간. 스택 영역의 실제 데이터들이 저장되어있음
스택 영역 - 힘의 참조값(주소값), 기본 자료형, 메서드 내부 기본자료형 변수. 메서드 종료시에 메모리 삭제
참조 : https://lucas-owner.tistory.com/38

참조 글 일부
같은 기능을 하는 어플리케이션 일지라도, 메모리 관리에 따라 성능에 차이가 생긴다는 이야기다. 
메모리를 관리하지 않고 구성하게 된다면 StackOverFlow 가 발생하여 어플리케이션이 종료될수도 있다는 말이다, 
혹은 어플리케이션의 속도가 크게 저하 될수도 있다

+
회사 프로그램이 고객의 정보를 인메모리로 저장했다 메모리 부하가 온 적이 있음. 메모리가 아닌 캐싱으로 해결

Spring

어노테이션?

코드의 특별한 의미, 기능을 수행하도록 하는 기술
어노테이션 덕에 코드가 깔끔해짐

참조 : https://velog.io/@rara_kim/Spring-%EC%96%B4%EB%85%B8%ED%85%8C%EC%9D%B4%EC%85%98Annotation

DI / IoC ?

DI 의존성 주입

AOP란?

관점 지향 프로그래밍
정리 : 각 로직 공통된 관심사 묶어서 사용 ex) 로깅

Bean, Component?

참조 : https://giron.tistory.com/91

DB

인덱스(INDEX)

색인. 특정 컬럼 기준으로 정렬해놓은 상태
DB의 일부 사용량을 차지함
저장성능보단 조회 성능을 올림

인덱스 자료구조

  • B+Tree
    자식노드가 2개 이상인 B-Tree를 개선시킨 자료구조
    BTree LeafNode를 LinkedList로 연결하여 순차 검색을 용이하게 만듬.
    해시테이블보다는 나쁜 시간복잡도지만, 일반적으로 사용되는 구조

  • 해시 테이블
    컬럼의 값으로 생성된 해시를 기반으로 인덱스 구현
    시간복잡도 Map처럼 O(1)
    부등호(<,>) 같은 연속적인 데이터 순차 검색이 불가능하기 떄문에 사용에 적합하지 않음

인덱스 효율성

인덱스는 한 테이블당 보통 3~5개가 적당(정규화, 테이블 목적에 따라 개수가 달라짐)

  • 카디날리티(중복정도)가 높으면 인덱스 설정에 좋은 컬럼
    카디날리티가 높다 - 중복도가 낮다(값들이 대부분 다르다 - 고유한 학번)
    카디날리티가 낮다 - 중복도가 높다(값들이 대부분 같다 - 나이)

  • 선택도가 낮아야 인덱스 설정에 좋은 컬럼(일반적으로 5~10%퍼)
    선택도가 낮다 - 한 컬럼이 갖고있는 값 하나로 적은 row가 찾아진다(카디날리티 높은것과 동일)

선택도 계산
10개 데이터 학번 모두 고유, 이름 2씩 같음, 5명씩 나이가 같음
학번 1/10 = 10%
이름 2/10 = 20%
나이 5/10 = 50%

그러므로 학번이 인덱스 설정에 좋은 컬럼

참고 링크 : https://dev-coco.tistory.com/158

그 외

쓰레드

동시성 - 하나의 코어 / 멀티 쓰레드
병렬성 - 여러개 코어 / 단일 쓰레드

후기...
참 열심히 여러 가지를 많이 하고 싶었지만 병행은 쉽지 않았다..
그래도 포기하기 않고 끝까지 완주가 목표기 때문에 완주를 했다면 나름 목표는 달성했다는 생각이다
앞으로도 이런게 많이 나왔으면 좋겠다
1기가 나오면 주변 사람들에게 추천할 예정

댓글을 작성해보세요.