[항해99 취업 리부트 코스 학습일지] 3기 20일차 TIL(부제: 팀 스터디 열정적으로 한 날)

안녕하세요! delay100입니다.

오늘은 팀 스터디를 정말 열정적으로 한 날이에요!!

특히나 직접 HashSet, HashMap을 뜯고 씹고 즐기고 맛보고 했습니다.. 흐흐 

그리고 팀원분의 열혈 강의.. 너무 알차고 유익했습니다..!!(아래에 정리해두었음)

이제 시간이 많이 늦었으니 마저 Spring강의를 듣고 내일 9시에도 달려보겠습니다!!

---

오늘의 타임테이블

• 9시~10시 팀 스크럼(SI, SM, SERVICE 취업 관련 이야기)
• 10시~12시 2문제 해결 + 1문제 로직설계
• 12시~2시 더위먹어서 기절잠
• 2시~3시30분 문제 마저풀기
• 3시30분~6시15분 스프링 강의
• 6시15분~7시 저녁
• 7시~8시 CS(DB)공부
• 8시~8시50분 팀회의, CS
• 8시50분~9시30분 멘토님 순회
• 9시30분~10시40분 팀스터디 
• 10시40분~11시30분 spring강의 마저 수강(1주차 끝내기)

 

---

Q. 팀원끼리 한 CS 스터디

 

A1. 가상메모리

예를들어 RAM8기가 컴퓨터를 가지고 있는데, 멜론+크롬(웹 서핑)을 킨 상태.

멜론 프로세스, 크롬 프로세스 각각 메모리를 할당해야함

멜론 실행하는데 6기가, 크롬 3기가가 든다고 하면 9기가 메모리가 필요함

이 상황에서 안되니까 운영체제가 가상 메모리 공간을 만들어서 실제 8기가 메모리보다 더 쓸 수 있는 것

멜론, 크롬이 각각 가상 공간을 할당받고, CPU는 메모리를 어떻게 이동할건지 처리를 해주고, OS에서 DISK 가상공간을 만들어줌

가상메모리

 

A2. 스와핑, 스레싱?

- 스와핑: 메모리랑 디스크 프로세스를 계속 교환하는 작업

ex) 멜론을 들으면서 유튜브를 보고 있으면서 멜론을 또 틀고...

계속 이렇게 바꾸면 스와핑때문에 성능저하가 발생 가능 n코어n쓰레드(여러 멀티테스킹 많이 할 수 있음)

 

- 스레싱: 스와핑이 엄청 많이 발생해서 성능이 저하되는 것

cpu 코어를 늘리거나,, 메모리를 늘리거나 프로세스 수를 줄이거나 해서 해결해야함

수평확장보다는 수직확장을 해야 함

스레싱

페이지폴트(pagefault)가 무수히 많이 발생(disk와 ram의 교체작업)해서 cpu가 상대적으로 놀게되는 현상!

데이터를 일단 먼저 가져와야 하는 동작을 처리해야 CPU가 일할수 있기 때문에 일을 상대적으로 적게 하게됨

 

A3. 라운드로빈

CPU스케쥴링의 한 종류. cpu에게 시간을 공정하게 할당함

가장 공간을 최적화함

 

A4. 해시(Hash)

 

A4-1. 해시 기본

value -> 해시알고리즘 -> hashcode (단방향 - hashcode가 같은 값이 나올 수가 있기 때문)

HashMap은 배열로 구현되어 있음.

key값을 해싱함. 해싱한 값을 배열에 매핑함.

배열은 index로 처리함. hash된 결과값이랑 index랑 매치하여 저장함

예를들어, (value*1234567)%8 = hashCode결과 <-> 배열값 1:1 매핑(해시값이 같으면 같은 index칸에 들어감)

이 key값이 겹친거는 배열내에 LinkedList로 저장함, 이 LinkedList가 커지면 TreeSet으로 만듦

리해싱(Rehashing)을 통해 해시테이블의 50%가 차면 테이블 리사이징을 해서 해시테이블의 크기를 두배로 늘릴 수 있음

 

*리해싱

 

https://adela.love/posts/hashtable

Hash table과 Hash Collision 해결 방법

 

A4-2. 해시셋(HashSet)

해시셋의 내부 구조는 Map으로 되어있음(Map의 value가 없는거처럼 하는것)

HashSet이면 꼭 hashcode, equals를 override를 꼭 해야 함

HashSet 설명

 

object내의 equals와 hashCode

Fireball내의 @Override equals와 hashCode

**instanceof를 Fireball로 다운캐스팅 해줌, di랑 mass를 써야하니까(o가 fireball로 변함)

1.

기본은 ==(주솟값 비교, 동일성 비교)를 함

동등성비교 di, mass가 같으면 동등성비교를 하고 싶은 경우 equals를 override해야 함

di, mass가 값이 같은 경우에 true를 반환하도록

 

결국, 주소 없이 값만 비교하는 로직을 (오버라이드)equals메소드에 넣는거임!

 

2.

fb1, fb2는 동등하지만 다른 해시 코드를 가지고 있음. 따라서 hashCode를 override를 해줘야 함

fb1(8, 10) = (해시코드 계산)8*10 = 80

fb2(8, 10) = (해시코드 계산)8*10 = 80 

Object.hasCode(): 메모리 주소를 기반으로 hashcode를 생성함

결국, 각각 값들을 해시값으로 변환한 값을 찾는 로직을 (오버라이드)hasCode메소드에 넣는거임!

 

A4-3. 해시맵(HashMap)

의문 : HashMap의 key를 객체로 넣는다면 equals, hashCode 둘다 override해줘야 할까?

정답 : 맞음, 둘다 override해야 함! HashMap내부적으로 hashCode랑 equals 둘다 쓰고 있음

HashMap 내

 

---

Q2. 이번 주 진행된 팀 스터디에서 얻은 인사이트는 무엇인가요?

 

A1. 어제 질문에 대한 답

 

- 코딩테스트 풀 때 BufferedReader, BufferedWriter과 Scanner 차이

BufferedReader도 사용자가 받은걸 담아와서 한번에 가져오기때문에 시간적 이점이 있음,

BufferedWriter에 들고와서 flush로 원할때만 출력하기 때문에 출력 시간에 이점이 있음

 

- StringTokenizer, split차이

StringTokenizer은 (레거시) 클래스, split은 메소드임

StringTokenizer은 (레거시) 클래스 - jdk1.0부터 제공됨, java표준 디자인 원칙과 맞지 않아서 잘 사용하지 않으려는 추세 

 split은 메소드 - jdk1.4부터 제공됨. 내부 로직이 정규표현식으로 동작됨

둘다 속도차이가 그렇게 많이 나지 않음(split사용이 더 낫지 않을까?..)

 

A2. static 남용하면 안되는 이유

우선 static은 정적 변수임, static은 어느 곳에서든 접근 가능

- static 멤버 변수는 서비스가 내려가지 않는 이상 메모리에 계속 남아있음.(메모리 누수 가능, 메모리 관리 힘듦)

- 유지보수 어려움

- 다중쓰레드(쓰레드가 여러 환경)인 상태에서는 동기화 문제가 발생할 수 있음(여러 쓰레드에서 수정하려고 할때 동시성 문제 발생할 수 있음)

 

---

항해99 취업 리부트 코스를 수강하고 작성한 콘텐츠 입니다.

[할인]란에 “추천왕 3기 백지연” 입력 시 10만원 할인
(*얼리버드, 타 혜택 중복 적용 가능)

IT 커리어 성장 코스 항해99, 개발자 취업부터 현직자 코스까지