├── README.md ├── contents ├── MustStudy.md ├── QuestionList.md ├── algorithm.md ├── db.md ├── etc.md ├── experience.md ├── java.md ├── network.md ├── os.md ├── software-engineering.md └── spring.md ├── file.txt ├── file2 ├── make_title.sh └── result.txt /README.md: -------------------------------------------------------------------------------- 1 | # Tech Interview 2 | 3 | **기술 면접 대비를 위한 기본 개념을 정리하는 Repository 입니다.** 4 | 5 | > 자세한 내용은 contents 폴더에서 확인 가능하며 6 | 모든 문제에 대한 정리 & 짧은 답변은 [이곳](https://docs.google.com/spreadsheets/d/1gi9yQ_wlg2utcs15mkkktFG-0xgycFhgZvOb9KIqHH0/edit?usp=sharing)에서 확인 가능합니다. 7 | 8 | 9 |
10 | 11 | [![author](https://img.shields.io/badge/author-devham76-blue.svg)](https://github.com/devham76) 12 | [![HitCount](http://hits.dwyl.io/devham76/tech-interview-study.svg?style=popout)](http://hits.dwyl.io/devham76/tech-interview-study) 13 | 14 |
15 | 16 | 17 | **:book: Contents** 18 | 1. [Data Structure](#1-data-structure) 19 | 2. [Network](#2-network) 20 | 3. [Operating System](#3-operating-system) 21 | 4. [Database](#4-database) 22 | 5. [Design Pattern](#5-design-pattern) 23 | 6. [Algorithm](#6-algorithm) 24 | 7. [Java](#7-java) 25 | 8. [Spring](#8-spring) 26 | 9. [Software Engineering](#9-software-engineering) 27 | 10. [ETC](#11-etc) 28 | 29 | --- 30 | 31 | ## 1. Data Structure 32 | :arrow_forward: [답변 내용](/contents/datastructure.md) 33 | 34 | ## 2. Network 35 | :arrow_forward: [답변 내용](/contents/network.md) 36 | * tcp/udp의 차이점을 설명하라 37 | * 흐름제어기법중 슬라이딩 윈도우 방식에대해 설명하라] 38 | * 브라우저에 네이버홈페이지 url을 입력했을때 일어나는 과정을 설명해라 39 | * OSI 7계층에대해 설명하여라 40 | * Restful API란? 41 | 42 | * 3-way handshaking이란? 43 | * HTTP와 HTTPS의 차이는? 44 | * GET과 POST의 차이는? 45 | * TCP/IP 프로토콜 스택 4계층으로 구분짓고 설명하라 46 | * Session과 Cookie 차이는? 47 | 48 | * iocp 49 | * http keep alive / tcp keep alive 50 | * ssl 51 | * tcp udp 패킷구조 차이점 52 | * 리피터, 허브, 브릿지, 라우터와 L2, L3, L4, L7 스위치 차이점 53 | 54 | * HTTP 자세히 설명해주세요 55 | 56 | ## 3. Operating System 57 | :arrow_forward: [답변 내용](/contents/os.md) 58 | 59 | - OS란 무엇이며, 핵심 기능은? 60 | - 부팅이 되는 과정을 설명하시오. 61 | - 프로세스의 5가지 상태에 대해 설명하시오. 62 | - 메모리 계층 구조를 설명하시오. 63 | - 캐시와 버퍼의 차이점은? 64 | 65 | * 세마포어와 뮤텍스란? 차이점은 무엇인가? 66 | * 메모리 단편화란? / 페이징과 세그멘테이션? 67 | * 선점스케줄링과 비선점스케줄링, 그리고 해당하는 알고리즘 한개씩 말하시오 68 | * 문맥교환이란? 69 | * PCB란? 70 | 71 | * 가상메모리란? 72 | * Deadlock이란? 73 | * 프로세스의 메모리구조? 74 | * thrashing이란? 75 | * 프로세스간 통신하는 방법은? 76 | * Thread 가 3개 생성 되었을 때 t1, t2, t3의 순서가 보장 되는 코드를 짜 보세요. 77 | 78 | ## 4. Database 79 | :arrow_forward: [답변 내용](/contents/db.md) 80 | * Primary Key, Foreign Key, ER 모델이란? 81 | * 정규화에 대해서 말해보시오, 정규화의 목적은? 82 | * 무결성에 대해 말해보시오 83 | * 조인이 무엇인지?(inner, left, right, outer) 84 | * NoSQL이란? 기존RDBMS와 다른점은? 85 | 86 |
87 | 88 | * 트랜잭션이란?(+트랜잭션의 성질) 89 | * 2단계 락킹이란? 90 | * 공유락, 배타락이란? 91 | * 색인이란? 색인을 사용했을때 장단점? 92 | * 역정규화를 하는 이유는 무엇인가? 93 | 94 | * view관련 95 | * 어떤 이상현상 생길수있을지 96 | 97 | * MySQL을 사용하셨다면, 어떤 엔진을 사용했나요? 왜 사용했나요? 98 | 99 | ## 5. Algorithm 100 | ### :pushpin: [알고리즘 ps](https://github.com/devham76/AlgorithmPS) 101 | :arrow_forward: [답변 내용](/contents/algorithm.md) 102 | 103 | * quick sort가 일어나는 과정을 설명해주세요 104 | * insertion sort가 일어나는 과정을 설명해주세요 105 | * DFS와 BFS의 차이를 말해주세요 106 | * 이분 탐색 알고리즘에 대해 설명해주세요 107 | * 알고있는 정렬 알고리즘과 그 중 좋아하는 정렬알고리즘 설명해주세요 108 | 109 | * 두개의 stack을 이용해 queue를 구현하라 110 | * LinkedList의 원소를 역순으로 출력하는 방법은? 111 | * tree와 graph를 설명하라 112 | * 해싱의 충돌을 해결하는 방법들을 설명하라 113 | * huffman encoding에 대해 설명하라 114 | 115 | * 벨만포드 알고리즘과 다익스트라 알고리즘의 차이점? 116 | * MST 알고리즘(Spanning Tree란?) 117 | * 프림 118 | * 크루스칼 119 | * Floyd-Warshall 알고리즘 120 | 121 | * 프라이어리티 큐의 구조 설명 122 | * heap에서 delete 과정을 그려라 123 | * 16진수 수를 10진수로 변경하는 코드를 작성해보세요 124 | * 이진트리, 이진 검색트리, 힙이 각각 무엇인지 설명해주세요 125 | * 해시테이블과 이진 검색트리를 비교하고 장단점을 이야기해주세요 126 | * 메모리가 제한된 모바일 기기용 주소록에 사용할 자료구조를 설계한다면 어느쪽을 쓰는것이 좋을까요? 127 | 128 | * 해쉬 테이블/큐/스택을 구현해주세요 129 | * 트리/링크드리스트 구현해주세요 130 | 131 | ## 6. Java 132 | :arrow_forward: [답변 내용](/contents/java.md) 133 | 134 | * 자바 컴파일 과정을 설명하라 135 | * String, StringBuffer, StringBuilder의 차이점에 대해 설명하라 136 | * OOP의 4가지 특징 137 | * 오버로딩과 오버라이딩의 차이 138 | * HashMap과 TreeMap의 차이 139 | 140 | * GC에 대해 설명하라 141 | * 자바의 메모리구조는? 142 | * 동등성(equals)과 동일성(==)에 대해 설명하라 143 | * 제네릭과 와일드카드에 대해 설명하라 144 | * 멀티스레딩환경에서 동기화문제를 해결하는 방법에대해 설명하라 (syncronized, atomic, volatile) 145 | 146 |
147 | 148 | * java의 접근 제어자의 종류와 특징 설명해주세요 149 | * non-static 멤버와 static멤버의 차이 설명해주세요 150 | * final 키워드 (final/finally/finalize) 설명해주세요 151 | * 인터페이스와 추상 클래스의 차이(Interface vs Abstract Class) 설명해주세요 152 | * set, list, map의 차이와 각각의 인터페이스 구현체의 종류를 설명해주세요 153 | 154 |
155 | 156 | * java8을 써보셨나요? java7에서 8로 올라오면서 어떤게 달라졌나요? 157 | * this 키워드 158 | * 자바에서 tcp udp 소켓 생성 방법 159 | * 리틀엔디안 빅엔디안 160 | * Reflection 161 | * oop 5대 원칙 162 | 163 | ## 7. Spring 164 | :arrow_forward: [답변 내용](/contents/spring.md) 165 | * IOC 란? 166 | * DI 란? 167 | * AOP 란? 168 | * 흐름(웹브라우저에서 Spring MVC로 요청했을 떄) 169 | * Bean 객체란? 170 | * 스프링 디스패처 서블릿이란 171 | * MVC1과 MVC2 패턴의 차이 172 | * Bean 생성 원리 173 | * Spring에서 AOP를 구현하는 3가지 방법. 174 | * Spring을 쓰는 이유 175 | 176 | 177 | * 스프링 버전 몇 사용하셨나요? (버전별 차이) 178 | * 스프링 security 사용해봤나요? 179 | 180 | ## 8. Software Engineering 181 | :arrow_forward: [답변 내용](/contents/software-engineering.md) 182 | * sw공학이란? 필요한 이유? 좋은 설계란? 183 | * 형상관리란? 184 | * Singleton, Adapter, Template패턴은 어떤 것인가? 왜 사용하는지? 코드 구현해보시오 185 | * 코드 결합도와 응집도란? 186 | * 블랙박스/화이트박스 테스트란? 187 | 188 | * Agile 방법론이 무엇인지 설명해주세요 189 | * 소프트웨어 생명 주기 모델은 무엇이고 어떤 모델이 있는지 설명해주세요 190 | * CVS, SVN, GIT에 대해서 아는대로 설명해 보시오. 191 | * 형상 관리를 잘못하면 어떤 문제가 발생하나요? 192 | * 객체지향과 절차지향 차이 설명해주세요 193 | 194 |
195 | 196 | * MVP패턴, MVVM패턴이란? 197 | * TDD란? 198 | * Java에서 Builder 패턴을 사용하는이유는? 199 | * Observer 패턴은? 200 | * Java에서 팩토리 메서드 패턴을 사용하는 이유는? 201 | 202 | 203 | ## 9. ETC 204 | :arrow_forward: [답변 내용](/contents/etc.md) 205 | 206 | * sass lass pass 207 | * Docker란 무엇인가요? 왜 사용하나요? 208 | * AWS를 사용해 본 경험이 있나요? 209 | * XML, json 차이 210 | * 최근 관심 있는 인터넷 이슈는 무엇인가요? 211 | * HTTP와 HTTP2의 차이 + HTTP3 212 | * apache와 nginx차이 213 | 214 | ## 10. 기술 외의 질문 215 | * 어떤 역할을 맡았고, 무슨 기술을 썼으며, 어떤 어려움이 있었고 어떻게 해결했는지 216 | * 작성한 프로젝트의 보안은 어떻게 신경썼나요? 217 | * 코딩테스트문제에서 뭐가 인상깊거나 아쉬웠는지 간단히 218 | * 어떤 실패를 했고 어떻게 극복했고 어떤것을 얻었는지 219 | * 대용량 데이터 처리를 위한 서비스 아키텍처에 대해 설명해 주세요. 그에 대한 기술도 함께 말씀해 주세요. 220 | * 무슨과목좋아하는지 221 | * 챗봇은 어떤엔진으로 구축햇는지 222 | * 우리회사에서 뭐하고싶은지 223 | * 알림톡데몬 유지보수 224 | * 개발이좋은지 유지하는게좋은지? 225 | * 전산이 적성에맞는지 226 | 227 | * 저희 회사에 대해 궁금한건 질문 해보세요 228 | 229 | :arrow_forward: [답변 내용](/contents/experience.md) 230 | 231 | --- 232 | 233 | # Reference 234 | -------------------------------------------------------------------------------- /contents/MustStudy.md: -------------------------------------------------------------------------------- 1 | 2 | 3 | 로드밸런싱 4 | - 적용 알고리즘 5 | https://post.naver.com/viewer/postView.nhn?volumeNo=27046347&memberNo=2521903 6 | 7 | 32비트 가상메모리 8 | 9 | 비동기 서버 처리 10 | 11 | https://poiemaweb.com/js-async 12 | https://webclub.tistory.com/605 13 | 14 | 웹트래픽폭주 15 | https://blog.naver.com/PostView.nhn?blogId=tmondev&logNo=220731906490 16 | 17 | 분산서버 18 | https://d2.naver.com/helloworld/6070967 19 | https://www.devkwon.com/posts/category/%EB%B6%84%EC%82%B0%EC%84%9C%EB%B2%84%EC%B2%98%EB%A6%AC 20 | https://kkwonsy.tistory.com/66 21 | 22 | 23 | 24 | 25 | 면접 준비 26 | https://brunch.co.kr/@adrenalinee31/6 27 | https://goodgid.github.io/18-Second-Half-Line-2st-Interview/ 28 | -------------------------------------------------------------------------------- /contents/QuestionList.md: -------------------------------------------------------------------------------- 1 | 1. 주로 내가 했던것 위주로 디테일 하게 기술셋 2 | - 손으로 종이에 다 그려보면서 면접장에서 설명할수 있도록 연습해서 감 3 | 4 | 2. 어떤 기술에 관심있어서 어떤 일을 경험했는지? 5 | - 서버 개발에 관심이있다. 6 | - 큰 트레픽을 다루는 회사들은 java와 spring을 선호하기 때문에 그 기술위주로 공부하고 7 | - aws를 이용해서 프로젝트를 배포해보고 8 | 9 | 3. 전 단계 면접에서 대답 못한 질문을 또 못함 10 | - 비동기 프로그래밍 11 | - db엔진 12 | - get에 body가 들어가면? 13 | - 이진검색, 이진검색트리 14 | - bfs,dfs구현할수있는 자료구조 15 | - 프로젝트내의 트랜잭션 사용했는지 16 | 17 | 4. 열심히 회사가 시키는 일만 했던 지원자 18 | - 사실 그랬다. 19 | - 그래서 퇴사 이후에 진짜 하고 싶은 일을 찾기 위해서 리엑트와 자바를 공부해보고 자바가 더 재미있어서 본격적으로 자바를 공부했다. 20 | 21 | 5. 자신이 사용했던 기술에 관해서 이해가 없던 지원자 22 | - 작성한 프로젝트 버전, 사용한 기술 다시보기 23 | 24 | 6. 본인이 사용한 기술을 왜 쓰는지, 어떻게 동작하는지 꼭 찾아보도록 하자 25 | - spring 왜 써요? 26 | - mvc패턴 왜 써요? 27 | - aws 왜 써요? 28 | - git 왜 써요? 29 | - jpa 왜 써요? 30 | 31 | 7. 왜 당사에 지원을 하게 되었는지, 입사를 하게 된다면 어떻게 일을 하려고 하는지 스토리 만들어 볼것 32 | - 10만건의 트래픽을 경험하면서 책임감과 뿌듯함을 느끼면서 더 큰 트래픽을 감당할 수 있는 서버 개발자로 성장하고 싶기 때문에 지원하게되었다. 33 | - 또 글로벌 서비스를 개발할수 있기 때문에 지원했다. 34 | 35 | - 입사를 하게 된다면, oo사의 서버를 어떻게 구성하고 있는지 배우고 싶고 36 | 37 | 38 | 8. 자식을 습득하고, 개발스킬을 향상시키는것과 어떤일이든 꾸준히 하는 모습을 보여주는 것이 중요 39 | - 개발 블로그, TIL, 사이드 프로젝트를 통해서 관심분야에 대한 애정을 가지고 공부한 내 모습을 보여주자. 40 | - 기억보다 기록을 !! 41 | 42 | 9. 정말 본인이 관심 있고 흥미를 가지는 부분에 대해서는 깊게 파헤쳐 보는 것이 중요 43 | - 네트워크, 서버 개발. 44 | - 신기해신기해 ~!! 45 | - 내가 짠 코드로 통신하고 46 | 47 | 10. 본인의 분야에 정말 최고의 전문가가 되겠다는 마음가짐이 중요 / 자기 분야에 관한 명확한 자기 색깔을 가지길 48 | 49 | - 서버 개발의 최고 전문가가 되려면? 50 | - 신입개발자를 지원하는 나는, cs기초지식을 다지고 내 프로젝트에 어떻게 녹여 낼 수 있는지 고민해보자. 51 | 52 | 11. 본인이 한 일과 역할을 구체적으로 어필 / 성장하지 않는 개발자는 필요없음 53 | - 실무 54 | - 알림톡 서비스 55 | - 유지 보수, 운영 56 | - 빠른 장애에 대응하기 위해 57 | 58 | -> 지금의 나라면, 59 | - 문제 60 | 서버를 한대만 뒀기 때문에, 장애 발생시에 서비스가 중단되는 문제가 있었다. (특히 새벽에. 아침에 중단됬다는 메일 몇백개가 온적이 있다.) 61 | - 해결 방안 62 | 서버를 한대만 두지 않고, 여러대를 둬서 장애가 발생하면 장애를 발생 시킨 요청을 제외하고 이후의 요청은 다른 서버에서 작업을 계속 할수 있도록 하겠다. 63 | 64 | - 문제 65 | 서버에 한 업체가 대량의 메세지 요청을 보내면, 다른 업체의 메세지는 한참 있다가 전송된다 66 | - 해결 방안 67 | 업체마다 메세지 요청 프로세스를 두면 되지 않을까? 68 | 69 | 70 | - 챗봇 71 | - 빠른 기능 확장을 위해 코드를 모두 재정비 72 | - 안되는것에 집중하지 않고 해결방법에 집중해서 73 | 74 | - 취업기록웹 75 | - 잘한점 : 대부분 처음 경험해보는 기술들로 서비스를 개발하고 배포까지 한것 76 | - 아쉬운점 : 로그인 기능이 있지만 거의 내 개인서비스라서 다른사람의 피드백을 받지 못한점이 아쉽다. 77 | 78 | 79 | 자신이 진행했던 프로젝트에 대해 완벽하게 이해하는 것이 중요하다고 생각합니다. 프로젝트의 목적과 허점에 대한 대비, 사용한 기술에 대한 방법론 등 세세하게 물어보십니다. 또한 직무 분야에 대한 이론적 지식이 충분해야한다고 생각합니다. 단순하게 내가 이걸 안다로 끝이 아닌 완벽하게 기술을 체화하여 타인을 이해 시킬 수 있는 정도의 수준이 되어야 할 것입니다. 80 | 81 | "내가 이 프로젝트에 기여했는가?"를 알고 싶은 것을 넘어 "이 프로젝트를 하며 어떤 생각을 했고 어떤 결정을 내렸는가?" 82 | 83 | 그 기능이 구체적으로 어떤 기술을 써서 만들어진건데요? 84 | 85 | Q. 다른 지원한 곳은? 86 | 87 | Q. 자기소개 88 | 89 | 90 | Q. 프로젝트 진행시 가장 중요시 여겼던 부분은? 91 | 92 | Q. 서비스 운영하면서 가장 중요시 여겼던 부분? 93 | - 많은 사람들이 리얼타임으로 이용하는 서비스 였기 때문에 장애가 나지 안도록 최대한 꼼꼼하게 코드를 작성했고 94 | 95 | Q. 로드 밸런싱 어떻게 했어? 96 | 97 | Q. 엔진엑스 세팅 작업 자세히 말해줘 98 | 99 | Q. 기술적인 도전은 뭐했어? 100 | 101 | Q. 트래픽 관점에서 대처했던 부분은 있어? 102 | 103 | Q. 서버 직군에서 뭐하고 싶은지? 104 | - 대용량 트래픽을 어떻게 처리하는지 배우고 개발하고 싶습니다. 105 | 106 | Q. 그걸 하기 위해 공부한게 있나요? 107 | - 대용량 트래픽을 다루는 기업은 보통 java와 spring을 사용해서 공부하고 웹애플리케이션을 만들고 108 | - AWS에 배포했다. 109 | - CI/CD를 이용해 안정적인 서비스를 제공하고 있기때문에 Travis CI와 AWS를 이용해 구축해봤다. 110 | - https통해서 보안에 신경썼다 111 | - 기술로 구현해보지는 못했지만, 이론적인걸 공부해봤다 112 | - 로드밸런싱, NoSQL, MSA, MQ 같은 기술들을 이용하는 걸로 알고있다. 113 | 114 | 115 | Q. 스스로 장점이 뭐야? 116 | - 어떤 사람이나 상황을 겪게 되면, 항상 배우려는 자세를 가지고 배울점을 찾고 그것 적용하려고 하는것 117 | - 솔루션 회사에서 일할때 사장님개발자의 코드를 보고 깨끗하고 읽기 쉬운 코드에 대해 배우게됬고 이것을 제 프로젝트에 적용하려고 노력해본 경험이 있습니다. 118 | 119 | 120 | Q. 단점이 머야? 121 | - 질문하기를 어려워 함 / 일정시간을 가지고 혼자 해결해보고 실패시, 어떤점이 문제이고 어떻게 해결하고 싶은지 잘정리해서 커뮤니티or동료개발자에게 질문 122 | 123 | Q. 개발적으로 수업때문에 읽은 책 말고 읽은 책과 책 제목은? 124 | - 하루 3분 네트워크 교실 125 | - 스프링 퀵 스타트 126 | - 쉽게 배우는 운영체제 127 | - 최근에는 클린코드를 읽고 있습니다 128 | 129 | 130 | Q. 개발 지식 쌓는 방법은 어떻게? 131 | - 깊게 알아야 하는 지식은 책을 주로 찾아보고 132 | - 빠르게 개념을 알고싶은 지식은 구글링하거나 유튜브에 검색 133 | 134 | Q. 서버 개발자 되고 싶은데 부족한 부분 뭐라고 생각해? 135 | - oo사 같이 실제로 대규모의 서비스를 운영해본 경험이 없어서 실제로 어떤 아키텍쳐를 가지고 개발하는지에 대한 지식이 부족하다고 생각 136 | 137 | Q. 뭘 잘할꺼같아? 138 | - 오랜시간 집중하기 보다 단기간에 폭팔적으로 집중할수있고 139 | - 느긋한 성격은 아니기 때문에 140 | - 단기간에 빠르게 집중해야하는일 141 | 142 | Q. 어떤 개발자가 되고싶어? 143 | - 개발할때 즐거운 개발자. 144 | - 항상 즐겁고, 다른 개발자 존중, 배운것을 나눌수있는 개발자 145 | - 함께 개발하고 싶은 개발자 146 | - 유튜브 노마드코더, 책저자 이동철님, 핌즈 사장님 147 | 148 | Q. 좋은 코드를 짜기 위해 어떤 것을 생각해? 149 | - 자료구조를 많이 생각한다 150 | -> 알고리즘 문제를 많이 풀면서 여러가지 자료구조를 공부하고 적용하는 방법을 배우게됬다. 프로그램의 시간,공간의효율을 위해 자료구조를 많이 생각한다. 151 | 152 | - 하나의 함수에 많은 일을 넣지않는다 153 | -> 대학시절과는 다르게 실제 서비스 개발을 하면서 기능의 추가나 유지보수를 경험. 이를 위해서는 하나의 함수에 너무 많은 일처리를 하면 안된다는 것을 배웠다. 154 | 155 | - 변수이름 적절하게 짓기 156 | -> 변수와 함수이름만으로 어떤일을 하는 코드인지 알수있도록 쉬운 코드를 작성하려고 노력한다 157 | 158 | 159 | Q. 제일 잘 짠 함수명 뭐야? 160 | - 어떤일을 하는지 구체적으로 작성, 줄여쓰지말고 정확하게 입력 161 | - 구체적으로 적지 않으면, 이함수가 어떤일을 하는지 내용을 직접 읽어봐야 알고 162 | - 줄여쓰면, 다른 개발자나 미래의 내가 이 함수를 찾을때 힘들다. 163 | 164 | Q. 앞으로 볼 예정인 책 있어? 165 | - 이팩티브자바 ; 166 | 167 | Q. NoSQL에서 No의 무슨 뜻이야? 168 | - rdbms가 아니다. 169 | 170 | Q. 의견 불일치 시 어떻게 했어? 171 | - 제 의견에 대해 타당한 근거와 데이터를 제시하고 172 | - 설득이 되지 않는다면, 우리 팀의 목표에 어긋나는 방향이 아니라면 상대의 의견에 동의하는 방향 173 | 174 | 175 | Q. 마지막 할 말 176 | - 면접의 기회를 생각지도 못했는데 주셔서 너무 감사하다. 이 면접은 제 지식이 뛰어나기보단 앞으로 성장할 가능성이 많다고 판단해주셔서 주신 기회라고 생각한다. 꼭 입사해서 성장한 모습을 보여드릴 기회가 있었으면 좋겠다. 177 | 178 | 1. Java Equals 손코딩 179 | 2. 입사 이유 및 포부 180 | 181 | 이전엔 어떻게 일을했는지. 팀으로 일하는 방식 182 | 실수 자료형에서 부동소수점의 precision 과 관련된 문제를 내셨습니다 183 | 184 | 해외 협력사와 커뮤니케이션할 때 어떻게 할 것인가, 플랫폼이란 무엇인가 185 | 면접답변 혹은 면접느낌 186 | 커뮤니케이션 전 필요 데이터 준비 완료 후 미팅 내용 정리하겠다, 플랫폼에 대해선 답변 못함 187 | 188 | 189 | ### 업무할때의 성격적 장 단점 190 | 191 | ### 관심 있는 분야 192 | - 대규모 서비스 아키텍처 개발 193 | - 이전에 비슷한 경험이있고 그때 굉장히 뿌듯하고 짜릿했다. 194 | 195 | 196 | ### 남들과 차별 포인트는 ? 강점은? 197 | - 서버 개발자는 책임감... 198 | 왜냐면, 설계과 코드에 의해서 서비스가 무너지느냐 운영되느냐가 결정되기 때문이라고 생각. 199 | 서비스를 어떻게 하면 안정적으로 운영할수 있을지에 대해 고민해본 경험이 있다. -> 어떤것이 작지만 중요한 부분일까 로그를 어디에 남기도록해야 될까 고민했다. 이게 가장어려웠고 중요한 부분이라고 생각. 로그를 아무데나 남기게 하면 수많은 트래픽에 의해서 메모리 낭비만 하게 되니까 의미있는 로그를 찍을수 있도록 노력. 200 | 201 | - GC에 대해서 설명 202 | 203 | 204 | 서비스 개선점 205 | 206 | , 오로지 면접자가 자신의 상황 속에서 어떤 지식을 얼마나 잘 배워왔는가를 중점적으로 평가했 207 | 208 | 대규모 분산 서비스 209 | 210 | 둘째로, 자신만의 극복담을 생각해 가시면 좋습니다. 211 | 학습, 혹은 프로젝트 중에 어떤 문제가 있었고 나는 이런 과정을 통해 해결했다 212 | 개인의 문제 해결 능력도 꽤 중요시 213 | 214 | - 기술의 극복담 215 | -> 책을 보고 로그인하는 부분을 구현했는데 조금 변경하려니까 잘안됐다.-> 원인을 파악하기 위해 코드를 보지 않고 이것저것 만져보고 구글링했다. 역시 안됐다 -> 원인을 파악하기 위해 코드의 구조를 확인하고 구조를 하나씩 뜯어보니까 생각보다 너무 쉬운 부분에서 해매고 있었다. 216 | - 앞으로는 오류가 생기면, 무작정 구글링하지 않고, 먼저 오류 메시지가 가르키는 곳에서부터 차근히 코드를 확인해야겠다. 217 | 218 | - 협업의 극복담 219 | 220 | 221 | 222 | 기초 지식을 탄탄히 하시고, 이를 다른 프로젝트에서 어떻게 응용할 수 있을지 잘 고민해보셨으면 합니다. 223 | 본인이 소화한 지식을 동원해서 다른 프로젝트에 적용해볼 수는 있을 것입니다. 224 | 225 | 내가 공부한 지식을 지원 분야에 어떻게 사용할 수 있을까? 226 | 227 | ### 자기가 어떻게 기여할 수 있는지?(뒷받침할만한 능력과 경험 제시) 228 | - 229 | - oo사 만큼 큰 트래픽은 아니었지만, 쉽게 겪을 수 없는 트래픽을 경험해봐서 때문에 서버를 안정적으로 운영하는것이 얼마나 사용자에게 큰 영향을 줄수있는지 알고있다. 230 | 231 | - 이렇게 서버에 관심이 많아서 N/W와 운영체제 같은 기본지식을 스터디원과 함께 공부하고 실무에서 서버 사이드는 어떤 기술을 사용하는지 공부하고 해볼수있는 것들을 실습해보곤했다. 232 | - 이론적인 지식을 바탕으로 실무 기술을 빠르게 이해할 수 있을것이다. 배운것을 실제로 어떻게 사용하고 있는지 내부 작동 구조를 얼른 보고 더 배우고 싶다 233 | 234 | 235 | 236 | Q) 메시지 전송 시스템 운영했다고 하셨는데 시스템 구성이 어떻게 되어있나요? 237 | - 여러가지 서비스들이 있었는데, 그 서비스들이 메시지 전송을 원하면 alim_queue라는 테이블에 데이터를 입력 238 | - alim_daemon이 외부 api를 이용해서 메시지를 전송하게 됩니다. 239 | 240 | - Messaging System을 사용하지 않았습니다. 241 | - 1차 면접때 관련된 질문을 해주셔서 처음듣는 부분이라 이후에 따로 공부를 해봤습니다. 242 | 243 | Q) 왜 MQ안썼다고 생각하세요? 244 | - 처음 서비스를 만들때는 규모가 작았기 때문에 사용을안했다고 생각합니다. 245 | - 제가 생각했을때 어떤 서비스에서 대량의 data를 alim_queue테이블에 insert하게 되면 246 | 당시에 myisam 엔진을 사용하고 있었기 때문에 테이블 전체에 lock이 걸리게 되서 247 | 핵심 데몬에서 select를 할수가 없고 다른 서비스도 insert할수없게 되서 문제가 발생할수있다고 생각합니다. 248 | 따라서 table과 서비스간의 결합도를 낮추고 좀 더 빠른 서비스를 위해 249 | MQ도입에 대해서 생각해보는것도 좋은 방법이라고 생각합니다. 250 | 251 | Q) 거기서 어떤일 하셨나요? 252 | - 주로 문의나 장애가 발생하면 대응했습니다. 253 | - 또 메시지 전송을 할 수 있는 새로운 서비스를 개발했습니다 254 | 255 | Q) 장애가 발생하면 어떻게 했나요? 어떤장애가 발생했었나요? 256 | - 장애가 발생해서 서비스가 중단되거나 특정한 메시지가 전송이 안된경우가 있는데 257 | - 원인에 대해서는 기억이 잘 나지 않습니다 258 | - 하지만 원인 해결을 하려고 로그를봤는데 적절한 곳에 로그가 잘 남겨있지 않아서 해결어려움 259 | - 이 오류를 겪고나서 필요없는 로그를 남겨서 메모리를 차지하지 않게 하고 260 | - 반드시 있어야할 정보를 남길수있도록 로그 남기는것에 신경을 썼습니다. 261 | 262 | Q) 만약에 서비스가 중단되면 어떻게 되나요? 263 | 1. 중지확인 264 | - 데몬이 멈추면 데몬을 감시하는 스크립트에 의해서 팀원들에게 메일이 전송됩니다 265 | - 또는 전송 현황 모니터링 페이지를 개발했는데, 그 화면을 보고 알 수 있습니다 266 | 2. 로그를 통해 발생지점 확인 후 267 | 3. 팀원과 공유 및 보고 268 | 4. 중단된 서비스 재시작 후에 정확한 문제 확인 269 | 270 | 271 | Q) 만약 다시 돌아간다면 272 | 1. 어떤 업체에서 상당히 많은 메시지 전송 요청을 한다면 273 | 나중에 메시지 전송을 요청한 것들은 한참을 기다리게 된다. 274 | - 전송 요청 업체별로 프로세스를 fork하는 건 어떨까 275 | 276 | 2. 메시지 전송 데몬은 alim_queue라는 TABLE을 polling해서 데이터를 가져 온 후, 가공해서 277 | api에 전송해서, 최종적으로 메시지를 전송하는데, 278 | 만약 어떤 서비스에서 대량의 데이터를 alim_queue에 insert하게된다면 279 | 당시에 MySQL에 MyISAM 스토리지 엔진을 사용하고 있었는데 table 전체에 lock이 걸리기 때문에 280 | 전송 핵심 데몬, 다른 서비스가 table에 select하거나 insert하지 못하는 단점 281 | - 스토리지 엔진 교체 ( row lock...) 282 | - 또는 MQ 도입 (엄청난 데이터양은 아니고 서비스 안정을 위해서 다양한 기능이 제공되는 RabbitMQ를 도입하는게 더 적절하지않을까?) 283 | 284 | Q) 이런 방법을 도입한다고 문제가 안생길까요? 다 해결될까요? 285 | - 당장 보이는 문제 말고도, 서버스를 운영하다보면 반드시 문제가 생길것 286 | - 이것을 예측하고 해결하는 것이 개발자가 하는일 287 | - 따라서 서비스에 대한 책임감과 끊임없는 기술 공부가 필요하다고 생각한다. 288 | 289 | Q) 어떤 서비스를 개발했나요? 290 | - 쇼핑몰에서 고객이 물건을 구입하면 구입한 정보가 서버측으로 들어오고 291 | - 쇼핑몰 직원이 언제 알림톡을 보낼지 설정한 내용을 바탕으로 292 | - 구입, 취소, 배송 등의 상황에 맞게 메시지를 전송하는 서비스를 만들었다 293 | - 새로운 로직을 추가해서 결국엔 alim_message라는 table에 데이터를 insert하면, 294 | - 핵심데몬이 데이터를 select해서 메시지를 전송하게 됩니다 295 | 296 | Q) 서비스 개발하면서 테이블 어떻게 구성했는지 설명해주실래요? 297 | - 스토리지 엔진은 MyISAM을 사용했습니다. 298 | - 당시에 선배개발자분들이 모두 MyISAM을 사용했기 때문입니다. 299 | - 그때는 시키는데로 해서 왜 그런지에 대해 생각을 못했는데, 최근에 생각을 해보니까 300 | - 고객들이 select를 너무 많이 해서 문제가 발생한 적이 있을 정도로 select양이 많습니다. 그래서 myisam 을 사용하신것같은데 301 | - 생각해보니맞다. 수정이 거의 없고 데이터 양 많고, select를 많이하니까 302 | - 고객정보, 구매아이디, 구매 내역 들을 컬럼값으로 설정했습니다 303 | -------------------------------------------------------------------------------- /contents/algorithm.md: -------------------------------------------------------------------------------- 1 | # 6. Algorithm 2 | **:book: Contents** 3 | 4 | * [quick sort가 일어나는 과정을 설명해주세요](#quick-sort) 5 | 6 | * [insertion sort가 일어나는 과정을 설명해주세요](#insertion-sort) 7 | 8 | * [DFS와 BFS의 차이를 말해주세요](#DFS와-BFS의-차이) 9 | 10 | * [이분 탐색 알고리즘에 대해 설명해주세요](#이분-탐색-알고리즘) 11 | 12 | * [알고있는 정렬 알고리즘과 그 중 좋아하는 정렬알고리즘 설명해주세요](#알고있는-정렬-알고리즘과-좋아하는-정렬알고리즘) 13 | 14 | 15 | * [두개의 stack을 이용해 queue를 구현하라](#두개의-stack을-이용해-queue를-구현하라) 16 | * [LinkedList의 원소를 역순으로 출력하는 방법은?](#LinkedList의-원소를-역순으로-출력하는-방법은?) 17 | * [tree와 graph를 설명하라](#tree와-graph를-설명하라) 18 | * [해싱의 충돌을 해결하는 방법들을 설명하라](#해싱의-충돌을-해결하는-방법들을-설명하라) 19 | * [huffman encoding에 대해 설명하라](#huffman-encoding에-대해-설명하라) 20 | 21 | * [벨만포드 알고리즘과 다익스트라 알고리즘의 차이점?](#벨만포드-알고리즘과-다익스트라-알고리즘의-차이점?) 22 | * [MST 알고리즘(Spanning Tree란?)](#MST-알고리즘(Spanning-Tree란?)) 23 | * [프림](#프림) 24 | * [크루스칼](#크루스칼) 25 | * [Floyd-Warshall 알고리즘](#Floyd-Warshall-알고리즘) 26 | 27 | 28 | --- 29 | 30 | * [프라이어리티 큐의 구조 설명](#프라이어리티-큐의-구조-설명) 31 | * [heap에서 delete 과정을 그려라](#heap에서-delete-과정을-그려라) 32 | * [16진수 수를 10진수로 변경하는 코드를 작성해보세요](#16진수-수를-10진수로-변경하는-코드를-작성해보세요) 33 | * [이진트리, 이진 검색트리, 힙이 각각 무엇인지 설명해주세요](#이진트리,-이진-검색트리,-힙이-각각-무엇인지-설명해주세요) 34 | * [해시테이블과 이진 검색트리를 비교하고 장단점을 이야기해주세요](#해시테이블과-이진-검색트리를-비교하고-장단점을-이야기해주세요) 35 | * [메모리가 제한된 모바일 기기용 주소록에 사용할 자료구조를 설계한다면 어느쪽을 쓰는것이 좋을까요?](#메모리가-제한된-모바일-기기용-주소록에-사용할-자료구조를-설계한다면-어느쪽을-쓰는것이-좋을까요?) 36 | * [LinkedList와 ArrayList의 차이](#LinkedList와-ArrayList의-차이) 37 | --- 38 | --- 39 | 40 | ## quick sort 41 | 42 | **정렬 과정** 43 | - (1)피벗을 기준으로 왼쪽에는 피벗보다 작은 수를, 오른쪽에는 피벗보다 큰 수를 놓는다. 44 | - (2)피벗을 기준으로 나뉜 두배열에서 각각 피벗을 정해서 (1)과 같이 정리한다. 45 | - 더이상 나눌수없을때까지 나눠서 정렬한다. 46 | 47 | **장단점** 48 | - 장점 : 속도가 빠르다 , 추가 메모리 공간을 필요로 하지 않는다 49 | - 단점 : 정렬된 리스트에 대해서는 퀵 정렬의 불균형 분할에 의해 오히려 수행시간이 더 많이 걸린다(따라서 피벗을 중간값으로 잡는것이 좋다.) 50 | - 신뢰성이 낮다. pivot에 따라 시간복잡도가 크게 달라지고, 최악의 경우 O(N2)이 나온다. 51 | - 따라서 안정적인 시간복잡도를 요구하는 곳(db쿼리 결과생성 등)에서 사용x 52 | - 불안정한 정렬이다. 중복되는 key값에 대해 순서대로 정렬되지 않는다. 53 | 54 | ```java 55 | public static int partition(int arr[], int left, int right) { 56 | 57 | int pivot = arr[(left + right) / 2]; 58 | 59 | while (left < right) { 60 | while ((arr[left] < pivot) && (left < right)) 61 | left++; 62 | while ((arr[right] > pivot) && (left < right)) 63 | right--; 64 | 65 | if (left < right) { 66 | int temp = arr[left]; 67 | arr[left] = arr[right]; 68 | arr[right] = temp; 69 | } 70 | } 71 | 72 | return left; 73 | } 74 | 75 | public static void quickSort(int arr[], int left, int right) { 76 | 77 | if (left < right) { 78 | int pivotNewIndex = partition(arr, left, right); 79 | 80 | quickSort(arr, left, pivotNewIndex - 1); 81 | quickSort(arr, pivotNewIndex + 1, right); 82 | } 83 | 84 | } 85 | 86 | ``` 87 | > [참고](https://creatordev.tistory.com/7) 88 | 89 | > :arrow_double_up:[Top](#6-algorithm) :leftwards_arrow_with_hook:[Back](https://github.com/devham76/tech-interview-studyw#6-algorithm) :information_source:[Home](https://github.com/devham76/tech-intervie-studyw#tech-interview) 90 | 91 | ## insertion sort 92 | - 모든 요소들을 차례로 이미 정렬된 배열 부분과 비교해서, 자신의 위치를 찾아 삽입하면서 정렬 93 | 94 | ```java 95 | public class InsertionSort { 96 | 97 | public static void main(String[] args) { 98 | 99 | int [] arr = {10, 2, 6, 4, 3, 7, 5}; 100 | 101 | for (int i = 1; i < arr.length; i++) { 102 | int standard = arr[i]; // 기준 103 | int aux = i - 1; // 비교할 대상 104 | 105 | while (aux >= 0 && standard < arr[aux]) { 106 | arr[aux + 1] = arr[aux]; // 비교대상이 큰 경우 오른쪽으로 밀어냄 107 | aux--; 108 | } 109 | arr[aux + 1] = standard; // 기준값 저장 110 | } 111 | printArr(arr); 112 | } 113 | 114 | public static void printArr(int[] arr) { 115 | for (int i = 0; i < arr.length; i++) { 116 | System.out.print(arr[i] + " "); 117 | } 118 | } 119 | } 120 | 121 | ``` 122 | 123 | > - [참고1](https://gmlwjd9405.github.io/2018/05/06/algorithm-insertion-sort.html) 124 | > - [참고2](https://marobiana.tistory.com/85) 125 | 126 | > :arrow_double_up:[Top](#6-algorithm) :leftwards_arrow_with_hook:[Back](https://github.com/devham76/tech-interview-studyw#6-algorithm) :information_source:[Home](https://github.com/devham76/tech-intervie-studyw#tech-interview) 127 | 128 | ## DFS와 BFS의 차이 129 | 130 | **DFS : 깊이 우선 탐색** 131 | - 단순 검색속도는 BFS보다 느리다 132 | - 자기 자신을 호출하는 순환 알고리즘의 형태 133 | 134 | **BFS : 너비우선탐색** 135 | - 큐나 인접리스트로 구현 136 | 137 | > :arrow_double_up:[Top](#6-algorithm) :leftwards_arrow_with_hook:[Back](https://github.com/devham76/tech-interview-studyw#6-algorithm) :information_source:[Home](https://github.com/devham76/tech-intervie-studyw#tech-interview) 138 | 139 | ## 이분 탐색 알고리즘 140 | 141 | - 과정 142 | 143 | ``` 144 | 정렬된 배열에서 특정값을 찾아내는 알고리즘이다. 145 | 배열의 중간에 있는 임의의 값을 선택해서 찾고자 하는 값과 비교한다. 146 | 찾고자 하는 값보다 작으면 중간값을 기준으로 좌측데이터를 값보다 크면 우측 대이터를 다시 탐색한다 147 | 동일한 방법으로 다시 중간값을 임의로 선택하고 비교한다. 148 | ``` 149 | 150 | - 시간 복잡도 : O(logN) , 중간값을 기준으로 계속 반으로 나누므로 151 | 152 | > :arrow_double_up:[Top](#6-algorithm) :leftwards_arrow_with_hook:[Back](https://github.com/devham76/tech-interview-studyw#6-algorithm) :information_source:[Home](https://github.com/devham76/tech-intervie-studyw#tech-interview) 153 | 154 | ## 알고있는 정렬 알고리즘과 좋아하는 정렬알고리즘 155 | 156 | ![정렬알고리즘](https://user-images.githubusercontent.com/55946791/81137452-d6848a00-8f99-11ea-90da-1b55ed10c83c.JPG) 157 | 158 | - 상황에 따라 다르다. 어떤 알고리즘이 최선이라고 할수 없다. 159 | 160 | 161 | **퀵, 힙, 병합** 162 | 1. 퀵 정렬(Quick sort) 163 | - 장점: 164 | - 분할과정에서 logN, partition에서 N시간이 걸려 평균적으로 O(NlogN) 으로 빠르게 정렬된다. 165 | - 최선의 성능을 낼 때는 병합정렬, 힙정렬보다 빠르다. 166 | 167 | - 단점: 168 | - 신뢰성이 낮다. 기준값(pivot)에 따라 시간복잡도가 크게 달라지고, 최악의 경우 O(N2)이 나온다. 고로, 안정적인 시간복잡도를 요구하는 곳(사용자에게 데이터베이스 쿼리 결과생성 등)에서 사용할 수 없다. 169 | - unstable 정렬이다. 중복되는 key값에 대해 순서대로 정렬되지 않는다. 170 | 171 | 2. 병합 정렬 172 | - 장점: 173 | - 안정적으로 준수한 시간 내에 정렬한다. O(NlogN) 시간 복잡도이다. 이는 매우 큰 장점이다. 174 | - stable 정렬이다. 175 | - 단점: 176 | - 추가적인 메모리가 필요하다. 임시배열 temp[]에 원본 배열의 복사가 필요하다. 배열의 크기가 상당히 큰 경우 부담이 될 수도 있다. 177 | 178 | 3. 힙 정렬 179 | - 장점: 180 | - 추가적인 메모리를 필요로 하지 않으면서, 최악의 경우에도 O(NlogN)을 보장한다. 181 | - 단점: 182 | - 데이터에 분포에 따라 결과가 다르게 나오는, 불안정성이 있다. 183 | - unstable 정렬이다. 184 | > [참고](https://wordbe.tistory.com/entry/Sort-%EB%8C%80%ED%91%9C%EC%A0%81%EC%9D%B8-%EC%A0%95%EB%A0%AC%EC%9D%98-%EB%AA%A8%EB%93%A0-%EA%B2%83) 185 | 186 | > :arrow_double_up:[Top](#6-algorithm) :leftwards_arrow_with_hook:[Back](https://github.com/devham76/tech-interview-studyw#6-algorithm) :information_source:[Home](https://github.com/devham76/tech-intervie-studyw#tech-interview) 187 | 188 | ## 두개의 stack을 이용해 queue를 구현하라 189 | 190 | ![stack 으로 queue](https://user-images.githubusercontent.com/55946791/81314079-a6d1a100-90c3-11ea-9a2d-f356150f14ee.jpg) 191 | 192 | ```java 193 | public static void main(String[] args) { 194 | Queue q = new LinkedList<>(); 195 | Stack s = new Stack(); 196 | 197 | Stack s1 = new Stack(); 198 | Stack s2 = new Stack(); 199 | 200 | for(int i=1; i<4; i++) { 201 | q.add(i); 202 | s.push(i); 203 | 204 | s1.push(i); 205 | } 206 | 207 | System.out.println("큐 출력값"); 208 | while(!q.isEmpty()) { 209 | System.out.println(q.poll()); 210 | } 211 | System.out.println("스택 출력값"); 212 | while(!s.isEmpty()) { 213 | System.out.println(s.pop()); 214 | } 215 | 216 | //------------------------ 217 | while(!s1.isEmpty()) { 218 | int num = s1.pop(); 219 | s2.push(num); 220 | } 221 | System.out.println("스택2 출력값"); 222 | while(!s2.isEmpty()) { 223 | System.out.println(s2.pop()); 224 | } 225 | ``` 226 | 227 | > [참고](https://pro-programmer.tistory.com/entry/%EB%91%90%EA%B0%9C%EC%9D%98-%EC%8A%A4%ED%83%9DStack%EC%9C%BC%EB%A1%9C-%ED%81%90Queue-%EA%B5%AC%ED%98%84%ED%95%98%EA%B8%B0) 228 | 229 | > :arrow_double_up:[Top](#6-algorithm) :leftwards_arrow_with_hook:[Back](https://github.com/devham76/tech-interview-studyw#6-algorithm) :information_source:[Home](https://github.com/devham76/tech-intervie-studyw#tech-interview) 230 | 231 | ## LinkedList의 원소를 역순으로 출력하는 방법은? 232 | - 1. 스택으로 구현 233 | - 2. 다른 링크드리스트로 구현(null객체) 234 | 235 | > [참고](https://hyerios.tistory.com/47) 236 | 237 | > :arrow_double_up:[Top](#6-algorithm) :leftwards_arrow_with_hook:[Back](https://github.com/devham76/tech-interview-studyw#6-algorithm) :information_source:[Home](https://github.com/devham76/tech-intervie-studyw#tech-interview) 238 | 239 | ## tree와 graph를 설명하라 240 | 241 | **트리와 그래프 차이** 242 | ![graph-vs-tree](https://user-images.githubusercontent.com/55946791/81316131-27919c80-90c6-11ea-9c27-c4b22eb67e10.png) 243 | 244 | - 245 | 트리와 그래프를 언제 사용할수있을까요? 246 | 247 | **트리** 248 | ![tree-terms](https://user-images.githubusercontent.com/55946791/81315154-e51b9000-90c4-11ea-9110-fef627fcd7c8.png) 249 | 250 | - 노드로이루어진 자료 구조 251 | - 트리는 계층 모델 이다. 252 | - node와 edge로 구성 253 | - 트리에는 cycle이 존재x 254 |
255 | 256 | **트리의 구성** 257 | 258 | ``` 259 | 1. 하나의 루트 노드를 갖는다 260 | 2. 루트 노드는 0개 이상의 자식 노드를 갖는다. 261 | 3. 그 자식의 노드 또한 0개 이상의 자식을 갖고 이 구조가 반복된다. 262 | ``` 263 | 264 |
265 | 266 | - 트리의 종류 267 | - 이진 트리, 이진 탐색 트리, 균형 트리(AVL 트리, red-black 트리), 이진 힙(최대힙, 최소힙) 268 | - 트리의 탐색 269 | - 중위 순회(in-order traversal): 왼쪽 가지 -> _현재 노드_ -> 오른쪽 가지 270 | - 전위 순회(pre-order traversal): _현재 노드_ -> 왼쪽 가지 -> 오른쪽 가지 271 | - 후위 순회(post-order traversal): 왼쪽 가지 -> 오른쪽 가지 -> _현재 노드_ 272 | - 트리의 구현 : 배열과 연결리스트 모두 사용하여 구현이 가능 273 | 274 | > [참고](https://gmlwjd9405.github.io/2018/08/12/data-structure-tree.html) 275 | 276 | **그래프** 277 | - 노드와 그 노드를 연결하는 간선을 모아 놓은 자료구조 278 | - 연결되어 있는 객체 간의 __관계__ 를 표현할 수 있는 자료구조 279 | 280 | **그래프 특징** 281 | - 네트워크 모델 282 | - 루트 노드라는 개념x 283 | - 부모-자식 관계 개념x 284 | - 순환 혹은 비순환이다 285 | - 방향 그래프와 무방햔 그래프가 있다. 286 | 287 | **그래프 구현** 288 | - 인접리스트 , 인접행렬로 구현가능 289 | 290 | **그래프의 탐색** 291 | - 깊이 우선 탐색(DFS, Depth-First Search) 292 | 루트 노드(혹은 다른 임의의 노드)에서 시작해서 다음 분기(branch)로 넘어가기 전에 해당 분기를 완벽하게 탐색하는 방법 293 | - 즉, 넓게(wide) 탐색하기 전에 깊게(deep) 탐색하는 것이다. 294 | - 사용하는 경우: 모든 노드를 방문 하고자 하는 경우에 이 방법을 선택한다. 295 | - 깊이 우선 탐색이 너비 우선 탐색보다 좀 더 간단하다. 296 | - 너비 우선 탐색(BFS, Breadth-First Search) 297 | 루트 노드(혹은 다른 임의의 노드)에서 시작해서 인접한 노드를 먼저 탐색하는 방법 298 | - 즉, 깊게(deep) 탐색하기 전에 넓게(wide) 탐색하는 것이다. 299 | - 사용하는 경우: 두 노드 사이의 최단 경로 혹은 임의의 경로를 찾고 싶을 때 이 방법을 선택한다. 300 | - Ex) 지구상에 존재하는 모든 친구 관계를 그래프로 표현한 후 Ash와 Vanessa 사이에 존재하는 경로를 찾는 경우 301 | - 깊이 우선 탐색의 경우 - 모든 친구 관계를 다 살펴봐야 할지도 모른다. 302 | - 너비 우선 탐색의 경우 - Ash와 가까운 관계부터 탐색 303 | 304 | 305 | > :arrow_double_up:[Top](#6-algorithm) :leftwards_arrow_with_hook:[Back](https://github.com/devham76/tech-interview-studyw#6-algorithm) :information_source:[Home](https://github.com/devham76/tech-intervie-studyw#tech-interview) 306 | 307 | ## 해싱의 충돌을 해결하는 방법들을 설명하라 308 | 309 | 310 | **체이닝** 311 | ![체이닝](https://user-images.githubusercontent.com/55946791/81363693-eb3e5a80-911e-11ea-887d-b2a66844f30b.png) 312 | 313 | - 같은 주소로 해슁되는 원소를 모두 하나의 __연결 리스트__ 에 매달아 관리한다 314 | - 체이닝에서 삽입은 효율성을 위해 연결리스트의 _맨 앞에 삽입_ 한다. 315 | - 맨 뒤에 삽입할 경우 삽입시마다 연결리스트를 따라 맨 끝으로 이동해야 하므로 낭비가 된다 316 | 317 | - 탐색과 삭제를 하려면 원하는 데이터를 찾기 위해 순차 탐색해야한다. 318 | 319 | **개방주소(open address)** 320 | - 체이닝과 같이 __추가 공간을 허용하지 않고__ 주어진 해쉬 테이블 공간 내에서 해결한다 321 | - 해쉬 함수를 계산해서 계산된 주소를 차지하고 있는 다른 원소가 없으면 그 자리에 넣고 322 | - 다른 원소가 있으면 __정해진 규칙__ 에 따라 다음 자리를 찾게 된다. 323 | - 정해진 규칙, 즉 다음 주소를 결정하는 방법은 3가지 이다. : __선형조사, 이차원 조사, 더블해슁__ 324 | 325 | **개방주소 - 선형 조사** 326 | ![개방주소 선형조사](https://user-images.githubusercontent.com/55946791/81364514-c5b25080-9120-11ea-8c50-9e27442cfbb2.png) 327 | - 가장 간단한 충돌 해결방법 328 | - 충돌이 일어나면 바로 뒷자리를 확인해서 비어있는 경우 저장한다. 329 | - 단점 : 특정 영역에 원소가 몰리면 성능이떨어진다. (검색시간, 삽입시간 저하) __1차군집화__ 330 | 331 | 332 | **개방주소 - 제곱 탐색(Quadratic Probing)** 333 | ![개방주소 이차원 조사](https://user-images.githubusercontent.com/55946791/81364513-c519ba00-9120-11ea-8299-04cbb87d950e.png) 334 | - 이차원 조사는 바로 뒷자리를 보는 선형 조사와 달리 __보폭을 이차함수에 의해 넓혀가면서__ 본다. 335 | - ex) i번째 해쉬 함수를 h(x)로 부터 i^2만큼 떨어진 자리로 삼을 수 있다. 336 | - ex) h(x), h(x)+1, h(x)+4, h(x)+9, h(x)+16... 337 | - 해시충돌 시 제곱만큼 건너뛴 버켓에 데이터를 삽입(1,4,9,16..) 338 | - 장점 : 선형 조사에서처럼 특정 영역에 원소가 몰려도 그 영역을 빨리 벗어날수있다. 339 | - 단점 : __2차 군집화__ 문제발생 340 | 341 | **개방주소 - 더블 해싱** 342 | - 2개의 해시함수를 사용해서, 충돌 발생시 다른 해시함수로 해시값을 만들어 원소를 저장한다. 343 | - 해시충돌 시 다른 해시함수를 한 번 더 적용한 결과를 이용함. 344 | 345 | - 장점 : 군집화 해결 346 | 347 | > [참고 - 더블해싱](https://m.blog.naver.com/beaqon/221300416700) 348 | 349 | > [참고 - 해시 충돌](https://itstory.tk/entry/%ED%95%B4%EC%8A%81%EC%97%90%EC%84%9C%EC%9D%98-%EC%B6%A9%EB%8F%99%ED%95%B4%EA%B2%B0Collision-Resolution) 350 | 351 | > :arrow_double_up:[Top](#6-algorithm) :leftwards_arrow_with_hook:[Back](https://github.com/devham76/tech-interview-studyw#6-algorithm) :information_source:[Home](https://github.com/devham76/tech-intervie-studyw#tech-interview) 352 | 353 | ## huffman encoding에 대해 설명하라 354 | 355 | > [참고](http://www.judgeon.net/problem.php?id=3022) 356 | 357 | > :arrow_double_up:[Top](#6-algorithm) :leftwards_arrow_with_hook:[Back](https://github.com/devham76/tech-interview-studyw#6-algorithm) :information_source:[Home](https://github.com/devham76/tech-intervie-studyw#tech-interview) 358 | 359 | 360 | ## 벨만포드 알고리즘과 다익스트라 알고리즘의 차이점? 361 | 362 | 다익스트라 - 우선순위큐 363 | 벨만코드 - 구현어떻게하는지 364 | 365 | - 최단 경로 : 주어진 두 노드 사이의 경로들 중에서 __최소 비용인 경로__ 를 찾는 것 366 | 367 | **다익스트라** 368 | - 하나의 정점, 다른 모든 정점으로의 최단경로 369 | 370 | - 다익스트라 알고리즘은 다음과 같다. (P[A][B]는 A와 B 사이의 거리라고 가정한다) 371 | 372 | 1. 출발점으로부터의 최단거리를 저장할 배열 d[v]를 만들고, 출발 노드에는 0을, 출발점을 제외한 다른 노드들에는 매우 큰 값 INF를 채워 넣는다. (정말 무한이 아닌, 무한으로 간주될 수 있는 값을 의미한다.) 보통은 최단거리 저장 배열의 이론상 최대값에 맞게 INF를 정한다. 실무에서는 보통 d의 원소 타입에 대한 최대값으로 설정하는 편. [5][6] 373 | 2. 현재 노드를 나타내는 변수 A에 출발 노드의 번호를 저장한다. 374 | 3. A로부터 갈 수 있는 임의의 노드 B에 대해, d[A] + P[A][B][7]와 d[B][8]의 값을 비교한다. INF와 비교할 경우 무조건 전자가 작다. 375 | 4. 만약 d[A] + P[A][B]의 값이 더 작다면, 즉 더 짧은 경로라면, d[B]의 값을 이 값으로 갱신시킨다. 376 | 5. A의 모든 이웃 노드 B에 대해 이 작업을 수행한다. 377 | 6. A의 상태를 "방문 완료"로 바꾼다. 그러면 이제 더 이상 A는 사용하지 않는다. 378 | 7. "미방문" 상태인 모든 노드들 중, 출발점으로부터의 거리가 제일 짧은 노드 하나를 골라서 그 노드를 A에 저장한다. 379 | 8. 도착 노드가 "방문 완료" 상태가 되거나, 혹은 더 이상 미방문 상태의 노드를 선택할 수 없을 때까지, 3~7의 과정을 반복한다. 380 | 381 | - 이 작업을 마친 뒤, 도착 노드에 저장된 값이 바로 A로부터의 최단 거리이다. 만약 이 값이 INF라면, 중간에 길이 끊긴 것임을 의미한다. 382 | 383 | > [참고](https://namu.wiki/w/%EB%8B%A4%EC%9D%B5%EC%8A%A4%ED%8A%B8%EB%9D%BC%20%EC%95%8C%EA%B3%A0%EB%A6%AC%EC%A6%98) 384 | > [코드 확인하기](https://devham76.github.io/datastructure/data_struture-Dijkstra/) 385 | 386 | **벨만 포드** 387 | - dp 관점 388 | - 다익스트라보다 느리다 389 | 390 | | 다익스트라| 벨만 포드| 391 | |--|--| 392 | |greedy 관점| dp관점| 393 | |벨만 포드 보다 빠르다 | 모든 수를 고려하기 때문에 다익스트라 보다 느리다| 394 | |그래프에 음의 가중치를 가진 간선x|그래프에 음의 가중치를 가진 간선o| 395 | 396 | >[참고](http://blog.naver.com/PostView.nhn?blogId=qbxlvnf11&logNo=221377612306&categoryNo=21&parentCategoryNo=0&viewDate=¤tPage=1&postListTopCurrentPage=1&from=postView) 397 | 398 | 399 | ## MST 알고리즘(Spanning Tree란?) 400 | 401 | ``` 402 | ※) 다익스트라 알고리즘 403 | "그래프"에서 출발점에서 목표점까지의 404 | 최단거리를 구할 때 사용하는 알고리즘 405 | ``` 406 | 407 | - 언제 사용하나요 ? 408 | - 통신구축 409 | 410 | **Spanning Tree** 411 | - 그래프 내의 모든 정점을 포함하고 일부 간선을 선택해서 만든 트리 412 | - 사이클 포함 x 413 | - 하나의 크래프에서 많은 신장 트리 존재할수있다 414 | 415 | **MST(Minimum Spanning Tree)** 416 | - 최소 신장 트리 417 | - 그래프에 있는 __모든 정점들을 가장 적은 수의 간선과 비용으로 연결__ 418 | 419 | - 정점 n개이면, 간선은 n-1개 420 | 421 | - MST는 최단거리가 아닐 수 있다. (최단 경로는 다익스트라) 422 | 423 | **MST 종류** 424 | - Kruskal , Prim 425 | 426 | >[참고](https://devham76.github.io/algorithm/mst/) 427 | 428 | ## 프림 429 | ![prim mst](https://user-images.githubusercontent.com/55946791/81514716-9ba09e80-936b-11ea-90da-ba7578715bcc.png) 430 | 431 | - __시작 정점에서부터 출발__ 하여 신장 트리 집합을 단계적으로 확장해나가는 방법 432 | - 정점에 연결 된 간선의 가중치 중 __가장 작은 가중치의 간선을 연결해__ 나가는 방식 433 | - __그래프에 간선이 많이 존재 하는 ‘밀집 그래프’의 경우 적합__ 434 | 435 | 436 | - 시간 복잡도 : 437 | 438 | - 구현코드 ? 439 | 440 | ## 크루스칼 441 | 442 | ![kruskal mst](https://user-images.githubusercontent.com/55946791/81514711-92afcd00-936b-11ea-8b39-23449e496f7e.png) 443 | 444 | 1. 그래프의 간선들을 가중치의 오름차순으로 정렬 한다 445 | 2. 정렬된 간선 리스트에서 순서대로 사이클을 형성하지 않는 간선을 선택한다. 446 | - 즉, 가장 낮은 가중치를 먼저 선택 447 | 448 | - kruskal : 그래프에 간선이 적게 존재 하는 __'희소 그래프'__ 의 경우 적합 449 | 450 | 451 | - 시간복잡도 : 452 | 453 | - 구현 코드 ? 454 | 455 | 456 | ## Floyd-Warshall 알고리즘 457 | - 모든 정점 에서 모든 정점으로 최단 경로 458 | - 거쳐가는 정점을 기준으로 최단 거리를 구한다 459 | - 다익스트라 - 가장 적은 비용을 하나씩 선택 460 | 461 | - https://blog.naver.com/ndb796/221234427842 462 | 463 | 464 | ## 프라이어리티 큐의 구조 설명 465 | - 들어간 순서에 상관없이 우선순위가 높은 데이터가 먼저 나온다 466 | - 구현 방법 467 | - 배열 468 | - 연결리스트 469 | - 힙 470 |
471 | 1. 배열 472 | - 데이터 삽입, 삭제 과정이 비효율적이다. 473 | - 삽입 위치를 찾기 위해 배열에 저장된 모든 데이터와 우선순위를 비교해야한다 474 | 475 | 2. 연결리스트 476 | - 삽입 위치를 찾기 위해 배열에 저장된 모든 데이터와 우선순위를 비교해야한다 477 | 478 | 3. 힙 479 | - 배열과 연결리스트의 단점 때문에 주로 힙으로 구현한다 480 | 481 | 482 | > :arrow_double_up:[Top](#6-algorithm) 483 | :leftwards_arrow_with_hook:[Back](https://github.com/devham76/tech-interview-studyw#6-algorithm) 484 | :information_source:[Home](https://github.com/devham76/tech-intervie-studyw#tech-interview) 485 | 486 | ## heap에서 delete 과정을 그려라 487 | - __삽입, 가장 마지막에 삽입 / 삭제, 루트 노드 삭제__ 488 | 489 | 490 | **힙** 491 | - __완진이진트리 + 이진탐색트리의 형태__ 492 | - 최대힙(부모노드>자식노드) / 최소힙(부모노드<자식노드) 493 | - 최댓값, 최솟값을 쉽게 추출할 수 있는 자료구조 494 | 495 | **삭제** 496 | - logN 497 | - __루트만 삭제 가능 , 삭제후 마지막 노드를 루트로 두고 우선순위비교__ 498 | 499 | 1. 루트노드를 삭제 500 | 2. 가장 마지막 원소를 루트 노드의 위치로 옮겨준다. 501 | 3. 자식노드와 우선순위를 비교해서 자신의 자리를 찾는다. 502 | 503 | 504 | ![힙 삭제](https://user-images.githubusercontent.com/55946791/81799451-525b7500-954c-11ea-93a0-fa92dab7657e.JPG) 505 | 506 | **삽입** 507 | - 마지막 노드에 삽입 logN 508 | ![힙 삽입](https://user-images.githubusercontent.com/55946791/81799454-538ca200-954c-11ea-9190-7883f0f5f8cc.JPG) 509 | 510 | 511 | > [참고1](https://hannom.tistory.com/36) 512 | > [참고2](https://gmlwjd9405.github.io/2018/05/10/data-structure-heap.html) 513 | 514 | > :arrow_double_up:[Top](#6-algorithm) 515 | :leftwards_arrow_with_hook:[Back](https://github.com/devham76/tech-interview-studyw#6-algorithm) 516 | :information_source:[Home](https://github.com/devham76/tech-intervie-studyw#tech-interview) 517 | 518 | ## 16진수 수를 10진수로 변경하는 코드를 작성해보세요 519 | > :arrow_double_up:[Top](#6-algorithm) 520 | :leftwards_arrow_with_hook:[Back](https://github.com/devham76/tech-interview-studyw#6-algorithm) 521 | :information_source:[Home](https://github.com/devham76/tech-intervie-studyw#tech-interview) 522 | 523 | 524 | ## 이진트리, 이진 검색트리, 힙이 각각 무엇인지 설명해주세요 525 | 526 | **이진트리 (Binary Tree)** 527 | ![이진트리](https://user-images.githubusercontent.com/55946791/81796516-7fa62400-9548-11ea-9647-f73733c9842e.JPG) 528 | - 노드의 최대 차수가 2인 트리 529 | 530 |
531 | 1. 편향 이진트리 532 | - 한 쪽으로 편향 533 | 534 | ![편향이진트리](https://user-images.githubusercontent.com/55946791/81798033-7f0e8d00-954a-11ea-86a5-d4ae54159be9.JPG) 535 | 536 | 2. 포화 이진트리 537 | - 이진트리에서 최대 노드의 수를 만족 538 | ![포화이진트리](https://user-images.githubusercontent.com/55946791/81796651-b2e8b300-9548-11ea-8193-fcdc96d86453.JPG) 539 | 540 | 3. 완전 이진트리 -> __힙__ (형태만) 541 | - 위에서 아래로, 왼쪽에서 오른쪽으로 __순서대로 채워진 트리__ 542 | 543 | ![완전이진트리](https://user-images.githubusercontent.com/55946791/81799024-b16cba00-954b-11ea-9d41-34c1c6e12905.JPG) 544 | 545 | 546 | **이진트리 vs 이진탐색 트리** 547 | 548 | - 이진트리 : 노드의 최대차수가 2인 트리 549 | 550 | - 이진탐색 : 정렬된 숫자에서 검색시, 한 숫자 선택, 검색 숫자보다 작으면 오른쪽, 크면 왼쪽 검사 551 | 552 | - 이진탐색트리 : 이진트리 + 조건 553 | - __조건 : 루트노드 > 왼쪽 자식 노드 && 루트노드 < 오른쪽 자식 노드__ 554 | - 트리가 이진탐색을 한다 555 | - __완전 이진트리가 아닐수있다__ 556 | - __탐색 방법__ : 전위, 중위, 후위 검색 방법이 있다 557 | 558 | ### 문제점 : 삽입,삭제를 하다보면 편향이진트리가 될수도있다. 559 | - 삽입,삭제,검색 최악 : O(N) / 평균 : O(logN) 560 | 561 | **이진탐색 트리** 562 | 563 | - 이진탐색트리 검색 564 | ![이진탐색트리 검색](https://user-images.githubusercontent.com/55946791/81798464-0b20b480-954b-11ea-9741-5e49fe464b29.png) 565 | 566 | - 이진탐색 삭제 567 | 568 | ``` 569 | 지우려는 노드에 570 | 1. 자식이 없을 때 571 | - 부모와 연결해제 572 | 2. 자식이 하나만 있을 때 573 | - 자식과 그의 부모노드를 이어준다 574 | 3. 자식이 두개 다 있을 때 575 | - 왼쪽 자식 노드들 중에 가장 큰값 또는 576 | 오른쪽 자식 노드들 중에 가장 작은값으로 교체 577 | ``` 578 | 579 | > [참고](https://zeddios.tistory.com/492) 580 | 581 | - 자식 하나일때 582 | ![이진탐색트리 삭제-자식하나](https://user-images.githubusercontent.com/55946791/81800767-512b4780-954e-11ea-90dd-347264164e1d.JPG) 583 | 584 | - 자식 두개일때 585 | ![이진탐색트리 삭제](https://user-images.githubusercontent.com/55946791/81798461-09ef8780-954b-11ea-9c54-d05f897b91cb.png) 586 | 587 | > [참고](https://galid1.tistory.com/176?category=746456) 588 | 589 | > :arrow_double_up:[Top](#6-algorithm) 590 | :leftwards_arrow_with_hook:[Back](https://github.com/devham76/tech-interview-studyw#6-algorithm) 591 | :information_source:[Home](https://github.com/devham76/tech-intervie-studyw#tech-interview) 592 | 593 | ## 해시테이블과 이진 검색트리를 비교하고 장단점을 이야기해주세요. 그리고 메모리가 제한된 모바일 기기용 주소록에 사용할 자료구조를 설계한다면 어느쪽을 쓰는것이 좋을까요? 594 | 595 | |비교|해시테이블|이진검색트리| 596 | |--|--|--| 597 | |시간복잡도 평균|key,value 충돌 없을때 O(1)| O(logN)| 598 | |시간복잡도 최악 - 선형으로 검색|O(N)|O(N)| 599 | |정렬| x| o| 600 | 601 | - 해시테이블이 이진검색트리보다 빠르다 602 | - 하지만, 정렬이 되지않아 정렬을 위한 메모리를 추가로 필요하다 603 | - 따라서 이진검색트리가 해시테이블 보다는 느리지만 O(logN) 의 속도도 충분히 빠르기 때문에 메모리가 제한된 모바일 기기에서는 더 적절하다. 604 | - 해시트리 ; 해시테이블때문에, 메모리가 추가로 필요할수있다. 605 | - 해시트리 ; 충돌이 많이 일어나면 , 성능이 낮아진다 606 | 607 | > :arrow_double_up:[Top](#6-algorithm) 608 | :leftwards_arrow_with_hook:[Back](https://github.com/devham76/tech-interview-studyw#6-algorithm) 609 | :information_source:[Home](https://github.com/devham76/tech-intervie-studyw#tech-interview) 610 | 611 | 612 | ## LinkedList와 ArrayList의 차이 613 | - ArrayList는 검색에 유리한 구조 614 | - 삽입 삭제가 자주 일어나면 LinkedList를 사용하는것이 좋다. 615 | 616 | - 이유 : ArrayList는 내부적으로 데이터를 배열에서 관리하며 데이터의 추가, 삭제를 위해 아래와 같이 __임시 배열을 생성해 데이터를 복사 하는 방법을__ 사용 하고 있기 때문에 삽입 삭제시 많은 복사가 일어나기 때문. 617 | 618 | 619 | > :arrow_double_up:[Top](#6-algorithm) :leftwards_arrow_with_hook:[Back](https://github.com/devham76/tech-interview-studyw#6-algorithm) :information_source:[Home](https://github.com/devham76/tech-intervie-studyw#tech-interview) 620 | -------------------------------------------------------------------------------- /contents/db.md: -------------------------------------------------------------------------------- 1 | # 4. Database 2 | **:book: Contents** 3 | * [Primary Key, Foreign Key, ER 모델이란?](#Primary-Key,-Foreign-Key,-ER-모델) 4 | * [정규화에 대해서 말해보시오, 정규화의 목적은?](#정규화에-대해서-말해보시오,-정규화의-목적은?) 5 | * [무결성에 대해 말해보시오](#무결성에-대해-말해보시오) 6 | * [조인이 무엇인지?(inner, left, right, outer)](#조인이-무엇인지?) 7 | * [NoSQL이란? 기존RDBMS와 다른점은?](#NoSQL이란?-기존RDBMS와-다른점은?) 8 | 9 |
10 | 11 | * [트랜잭션이란?(+트랜잭션의 성질)](#트랜잭션이란?(+트랜잭션의-성질)) 12 | * [2단계 락킹이란?](#2단계-락킹이란?) 13 | * [공유락, 배타락이란?](#공유락,-배타락이란?) 14 | * [색인이란? 색인을 사용했을때 장단점?](#색인이란?-색인을-사용했을때-장단점?) 15 | * [역정규화를 하는 이유는 무엇인가?](#역정규화를-하는-이유는-무엇인가?) 16 | 17 | * MySQL을 사용하셨다면, 어떤 엔진을 사용했나요? 왜 사용했나요? 18 | 19 | --- 20 | ## Primary Key, Foreign Key, ER 모델 21 | 22 | **Key 종류** 23 | db 키종류 24 | 25 | - Super key : 유일성 O, 최소성 X 26 | - Candidate key : 유일성 O, 최소성 O (키의 집합에서 하나라도 삭제하면 유일성 만족하지 못하는 성질) 27 | - Primary key : 후보 키 중에서 선정된 키. 유일성 O, 최소성 O / Null값 가질수 없다 28 | - Alternate Key : 후보 키에서 기본키를 뺀 모든 후보 키 29 | - Foreign Key : 다른 테이블의 Primary key를 참조하는 컬럼 30 | 31 | **ER 모델** 32 | - Entity Relation Model 33 | ![er모델](https://user-images.githubusercontent.com/55946791/81372824-40399b00-9136-11ea-9dff-889b52f5da33.png) 34 | - 개체(Entity), 애트리뷰트(Attribute), 관계성(Relation)으로 기술하는 데이터 모델을 말한다. 35 | 36 | > [참고](https://victorydntmd.tistory.com/126) 37 | 38 | ## 정규화에 대해서 말해보시오, 정규화의 목적은? 39 | 40 | **DB 정규화란 ?** 41 | - RDBMS의 설계에서 중복을 최소화하여 데이터를 구조화하는 프로세스 42 | - 연관성 있는 속성들을 분류하여, 각 릴레이션들에 이상현상이 생기지 않도록 하는 과정 43 | - 정규형에는 1NF, 2NF, 3NF, BCNF, 4NF, 5NF, 6NF 까지 있다 (보통 3정규형 까지 되어있으면 정규화 되었다고 한다) 44 | 45 | **정규화 종료** 46 | - 1NF 47 | - 2NF 48 | - 3NF 49 | 50 | 51 | **DB 정규화가 필요한 이유?** 52 | - DB설계를 잘못 하면 불필요한 데이터 중복으로 인해 공간이 낭비되고 부작용을 초래할수있다. 53 | - 이러한 부작용을 이상(Anomaly)이라고 한다. 54 | - 삽입이상, 갱신이상, 삭제이상이 있다. 55 | 56 | **이상 예제** 57 | - 기본키 : student_id, course_id 58 | ![db 정규화 예제](https://user-images.githubusercontent.com/55946791/81373708-56485b00-9138-11ea-9720-fc4f170775b9.JPG) 59 | 60 | **삽입 이상** 61 | - 세 데이터를 삽입하기 위해 불필요한 데이터도 함께 삽입해야 하는 문제 62 | - ex ) 아직 수업을 하나도 수강하지 않은 학생이 있다고 가정하자. 현재 KEY 를 학번과 과목코드로 지정해 놓았고 기본키로 쓰이는 컬럼은 NULL 이 될 수 없으므로 그 학생은 이 테이블에 추가 될 수가 없다. 굳이 삽입하려면 ‘미수강’ 같은 과목코드를 새로 만들어서 삽입해야 한다. 63 | 64 | **갱신 이상** 65 | - 중복 튜플 중 일부만 변경하여 데이터가 불일치하게 되는 모순 66 | - ex ) 야붕이 컴퓨터공학이 싫어서 음악학부로 옮기게 되는경우 ‘컴퓨터공학부’ 의 갯수는 과목코드의 갯수만큼 있으므로 모두 ‘음악학부’ 로 변경해주어야 한다. 이때 모두 변경하지 않고 두개만 바꾸는 경우 야붕은 컴퓨터공학부인지 음악학부인지 알 수 없게 된다. 67 | 68 | **삭제 이상** 69 | - 튜플을 삭제하면 꼭 필요한 데이터까지 함께 삭제되는 데이터 손실의 문제 70 | - ex ) 모찌가 수강정정기간에 MEC011101 라는 수업을 듣기 싫어져서 드랍하는 경우, 위 테이블에 반영하기 위해서는 모찌에 대한 행을 모두 삭제하게 된다. 수강취소를 반영하기 위해 학생등록정보를 모두 날리게 되는 것이다. 71 | 72 | 73 | > [참고] (https://yaboong.github.io/database/2018/03/09/database-normalization-1/) 74 | 75 | ## 무결성에 대해 말해보시오 76 | 77 | **무결성이란** 78 | - 데이터의 __정확성과 일관성을 유지하고 보증하는__ 것 79 | 80 | **개체 무결성** 81 | - 기본키로 설정된 컬럼은 고유한 값을 가지며 NULL허용X 82 | 83 | **참조 무결성** 84 | - 외래키 값은 NULL이거나 참조 릴레이션의 기본키 값과 동일해야 합니다. 85 | - 즉 릴레이션은 참조할 수 없는 외래키 값을 가질 수 없습니다. 86 | - 참조 관계에 있는 두 테이블의 데이터가 항상 일관된 값을 갖도록 유지하는것 87 | 88 | **도메인 무결성** 89 | - 특정 속성의 값이 그 속성이 정의된 도메인에 속한 값이어야 한다는 규정 90 | - ex) 주민등록번호에 알파벳입력되면 도메인 무결성 깨진것 91 | 92 | **고유 무결성** 93 | - 특정 속성에 대해 고유한 값을 가지도록 조건이 주어진 경우, 그 속성값은 모두 달라야 하는 제약조건을 말합니다. 94 | - ex)학생 릴레이션(테이블)에서 테이블 정의시 '이름' 속성에는 중복된 값이 없도록 제한했다면, '이름' 속성에는 중복된 이름이 있어서는 안됩니다. 95 | 96 | **NULL 무결성** 97 | - 특정 속성값에 NULL 이 올 수 없다는 조건이 주어진 경우, 그 속성값은 NULL 값이 올 수 없다는 제약조건을 말합니다. 98 | 99 | **키 무결성** 100 | - 한 릴레이션(테이블)에는 최소한 하나의 키가 존재해야 한다는 제약조건을 뜻합니다. 101 | 102 | > [참고](https://limkydev.tistory.com/161) 103 | 104 | ## 조인이 무엇인지? 105 | - inner, left, right, outer 106 | - 관련 있는 컬럼을 기준으로 행을 합쳐주는 연산 107 | ![SQL JOIN](https://user-images.githubusercontent.com/55946791/81374887-3fefce80-913b-11ea-99cd-366bfb6d7c7d.png) 108 | 109 | 110 | ## NoSQL이란? 기존 RDBMS와 다른점은? 111 | - NoSQL = Not Only SQL or Non relational Database 112 | 113 | 114 | **RDBMS** 115 | - 데이터는 엄격한 스키마(데이터 개체, 속성, 관계,제약조건)에 따라 table에 저장된다 116 | - 관계를 통해 연결된 여러개의 테이블에 저장 117 | - 사용 118 | - __데이터 자주 수정되는 애플리케이션 일때_ 119 | - __변경될 여지 없고, 명확한 스키마가 중요할경우__ 120 | 121 | - __장점__ 122 | - 명확한 데이터 구조 보장 (정해진 스키마에 따라 데이터를 저장하기 때문에) 123 | - __데이터 중복을 피해,__ 공간 절약 (각 데이터에 맞게 테이블을 나눠서 저장하기 때문) 124 | - __단점__ 125 | - 관계로 인한 시스템 복잡도를 고려하여 구조화 해야한다 126 | - 시스템이 복잡하면, query문 복잡, 성능 저하 127 | - 수평적 확장 어려움, 대부분 수직적 확장, 한계에 직면할 수 있다 128 | 129 | *NoSQL* 130 | - 분산처리 목적으로 나옴 131 | - 스키마X 관계X 132 | - 테이블과 같은 개념으로 컬렉션이라는 형태로 데이터를 관리 133 | - 사용 134 | - 정확한 데이터 구조 알 수 없거나 변경,확장 가능한 경우 135 | - __읽기가 많고, 변경이 적을때__ 136 | - __막대한 양의 데이터 다룰때__ (수평적 확장 용이) 137 | - __장점__ 138 | - 테이블간의 복잡한 관계를 생각 안해도 된다. 139 | - 스키마가 없어서, 유연하다. 언제든지 저장데이터를 조정하고 새로운 필드 추가 가능 140 | - __자주 변경도지 않는 데이터를 저장하기 유리하다__ 141 | - __수평적 확장에 용이__ ,(읽기, 쓰기가 빠르다) 142 | - __단점__ 143 | - __데이터 업데이트시, 중복될수__ 있어 저장 __데이터를 똑같이 관리__ 해줘야한다.(자유롭게 데이터 추가가능하여, 중복 저장될수있다) 144 | - 종류 : MongoDB, HBASE, Cassandra등 145 | >[참고](https://kimsangyeon.github.io/sql/nosql/database/2019/08/16/rdbms-nosql.html) 146 | 147 | **Redis** 148 | - Remote DIctionary System 149 | - 메모리 기반의 Key/Value Store 150 | - 빠른처리 (read/write) 속도와 검증괸 s/w 안정성 제공 151 | - 다양한 데이터 구조 저장 152 | - string, hash, lists, sets, sorted set, bitmap등 153 | - 사용하는곳 154 | - 인스타그램, 트위터 등 155 | 156 | **HBase** 157 | - 기존의 Redis NoSQL의 한계 158 | - 많은 Memory 공간을 필요, 분산 저장 시스템이 아님 159 | 160 | 161 | ## 트랜잭션이란?(+트랜잭션의 성질) 162 | 163 | - 의미 : (한 단위를 이루는) __일련의 연관된 DB조작__ 164 | - 데이터 __무결성__ 을 위해 가장 좋은 방법 165 | 166 | **1. 원자성** 167 | - 트랜잭션의 연산은 데이터베이스에 __모두 반영 or 전혀 반영되지 않아야 한다.__ 168 | 169 | **2. 일관성** 170 | - 트랜잭션이 그 실행을 성공적으로 완료하면 언제나 일관성 있는 데이터베이스 상태로 변환한다. 171 | - 시스템이 가지고 있는 __고정요소는 트랜잭션 수행 전과 트랜잭션 수행 완료 후의 상태가 같아야 한다.__ 172 | 173 | **3. 고립성** 174 | - 둘 이상의 트랜잭션이 동시에 병행 실행되는 경우 어느 하나의 트랜잭션 실행중에 다른 트랜잭션의 연산이 끼어들 수 없다. 175 | - __수행중인 트랜잭션은 완전히 완료될 때까지 다른 트랜잭션에서 수행 결과를 참조할 수 없다.__ 176 | 177 | **4. 영속성** 178 | - 성공적으로 완료된 트랜잭션의 결과는 시스템이 고장나더라도 영구적으로 반영되어야 한다. 179 | - 일단 커밋이 되면 트랜잭션에 의해 변경된 내용은 영구적이어야한다 180 | - DB시스템은 DB의 현재 상태가 유실되지 않도록 시스템 충돌 등의 문제로부터 복구할 수 있는 방법을 갖춰야 한다. 181 | 182 | > :arrow_double_up:[Top](#4-Database) :leftwards_arrow_with_hook:[Back](https://github.com/devham76/tech-interview-studyw#4-Database) :information_source:[Home](https://github.com/devham76/tech-intervie-studyw#tech-interview) 183 | 184 | ## 2단계 락킹이란? 185 | - 데이터가 읽거나 쓰거나 락을 해야하는데 186 | - 동시에 락을 걸수있기때문에 , 단계를 나눠서 생각해야한다 187 | - 확장단계 - 락을 걸수있고 188 | - 수축단계 - 언락 189 | - 공유락, 배타락을 따로 두고 임의로 병행접근못하게한다 190 | - 데드락 발생가능, 확장단계에서 수축단계를 기다릴수있기때문 191 | 192 | > :arrow_double_up:[Top](#4-Database) :leftwards_arrow_with_hook:[Back](https://github.com/devham76/tech-interview-studyw#4-Database) :information_source:[Home](https://github.com/devham76/tech-intervie-studyw#tech-interview) 193 | 194 | ## 공유락, 배타락이란? 195 | - 공유락 : 읽기만 196 | - 배타락 : 읽기+쓰기 197 | - 공유락이 걸려있을때 배타락이 허용가능한가요? 198 | - 공유락 일때 공유락은 가능. 배타락 불가능 199 | - 배타락일땐, 공유락 불가능. 배타락 불가능. 200 | 201 | > :arrow_double_up:[Top](#4-Database) :leftwards_arrow_with_hook:[Back](https://github.com/devham76/tech-interview-studyw#4-Database) :information_source:[Home](https://github.com/devham76/tech-intervie-studyw#tech-interview) 202 | 203 | ## 색인이란? 색인을 사용했을때 장단점? 204 | - DB에서 검색시, 테이블의 모든 데이터를 검색하면 시간이 오래걸린다 205 | - 컬럼의 값 & 해당 레코드가 저장된 주소를 키&쌍 으로 index로 만들어 관리하는것 206 | 207 | - 특징 208 | - 논리적/물리적으로 테이블과 독립적이다 209 | - 장점 : 검색 시 빠르게 탐색 210 | - 단점 : 새로운 값 추가, 삭제, 수정시 쿼리문 속도 느려진다(인덱스를 수정해야하기때문) 211 | 212 | >[참고](https://lalwr.blogspot.com/2016/02/db-index.html) 213 | 214 | >[인덱스란? Clustered Index/ Non-Clustered Index란?](https://s1107.tistory.com/38?category=242156) 215 | 216 | > :arrow_double_up:[Top](#4-Database) :leftwards_arrow_with_hook:[Back](https://github.com/devham76/tech-interview-studyw#4-Database) :information_source:[Home](https://github.com/devham76/tech-intervie-studyw#tech-interview) 217 | 218 | ## 역정규화를 하는 이유는 무엇인가? (★★★) 219 | - 220 | > :arrow_double_up:[Top](#4-Database) :leftwards_arrow_with_hook:[Back](https://github.com/devham76/tech-interview-studyw#4-Database) :information_source:[Home](https://github.com/devham76/tech-intervie-studyw#tech-interview) 221 | 222 | ## MySQL을 사용하셨다면, 어떤 엔진을 사용했나요? 왜 사용했나요? 223 | | 스토리 엔진 | 엑세스 패턴 | 224 | |--|--| 225 | |MyISAM | 추가 처리만 한다, select count(*) 를 많이 사용| 226 | |InnoDB| 갱신 빈도가 높다, 트랜잭션이 필요하다, 민감한 정보를 사용한다| 227 | 228 | 229 | ### 1. MyISAM 230 | - MySQL 5.5 이전까지 기본 스토리지 엔진 231 | - __Table-level Lock__ 232 | - 테이블 작업시 특정 행을 수정하려고 하면 테이블 전체에 락이 걸린다 233 | - 트랜잭션 미지원 234 | - 작업도중 문제가 발생해도, 이미 db안으로 데이터가 입력됨 235 | - __select작업이 많은 경우 효과적__ 236 | - 잦은 변경 및 삭제에는 성능이 좋지 못함. 237 | 238 | ### 2. InnoDB 239 | - MySQL 5.5 부터 기본 스토리지 엔진 240 | - 트랜잭션 지원 (ACID Transaction) 241 | - MyISAM 보다 data 저장 비율이 낮고, 데이터 로드 속도 느리다. 242 | - __Row-level Lock__ 243 | - 테이블작업시, 작업 시작하면 해당 row만 잠긴다. 244 | - insert, update, delete에 대한 속도가 빠르다 245 | - 민감한 정보를 갖는 table(회원 table, 돈 관련 table)에 사용하기 좋다 246 | - 비정상 종료시 복구 기능 247 | - 주로 데이터 입력 및 수정이 빈번한 높은 퍼포먼스를 요구하는 대용량 사이트에 적합 248 | -------------------------------------------------------------------------------- /contents/etc.md: -------------------------------------------------------------------------------- 1 | # 10. ETC 2 | **:book: Contents** 3 | 4 | * sass lass pass 5 | * Docker란 무엇인가요? 왜 사용하나요? 6 | * AWS를 사용해 본 경험이 있나요? 7 | * XML, json 차이 8 | * 최근 관심 있는 인터넷 세상의 이슈는 무엇인가요? 9 | * HTTP와 HTTP2의 차이 + HTTP3 10 | * apache와 nginx차이 11 | 12 | * Docker 13 | * SSH 14 | 15 | 16 | --- 17 | 18 | ## sass lass pass 19 | 20 | 1. SaaS, 사스 21 | - Software as a Service 22 | - 소프트웨어 서비스 23 | - 구글드라이브, 드랍박스, 와탭 등 24 | 25 | 2. PaaS, 파스 26 | - Platform as a Service 27 | - IaaS에서 한번 더 추상화한 서비스 28 | - 한번 더 추상화했기 때문에 __많은 기능이 자동화__ 되어 있다 29 | - AWS Beanstalk, Heroku등 30 | 31 | 3. IaaS, 아이아스 ,이에스 32 | - Infrastructure as a Service 33 | - 기존 물리 장비를 미들웨어와 함께 묶어둔 추상화 서비스 34 | - 가상머신, 스토리지, 네트워크, 운영체제 등의 __it인프라를 대여해주는 서비스__ 35 | - AWS EC2, S3등 36 | 37 | ## framework library 38 | 프레임워크 : 특정 프로그램을 개발하기 위한 여러 요소들과 메뉴얼인 룰을 제공하는 프로그램 39 | 라이브러리 : 프로그램을 개발하기 위해 쓰는 공구와 같은 도구들 40 | 공통점 : 프로그램을 쉽게 만들 수 있게 하는 공통된 목적이 있음 41 | 차이점 : 자유도, 프레임워크는 꼭 써야되는 것과 지켜야되는 룰이 있다. 라이브러리는 쓰든 안 쓰든 자기 마음이다. 42 | 43 | > [참고](https://engkimbs.tistory.com/673?category=763578) 44 | 45 | ## Platform 46 | 많은 사람이 쉽게 이용하거나 다양한 목적으로 사용된다 47 | - 소프트웨어에선 “여러가지 기능을 제공해주는 공통 실행환경”을 플랫폼이라고도 말하게도 되었습니다. 48 | - “서비스플랫폼”이란 다른 서비스들이 내 서비스를 쉽게 활용할 수 있게 해도록 해주는 인터넷 기반의 기술 환경을 말합니다. 49 | ![플랫폼이란](https://user-images.githubusercontent.com/55946791/82056589-1e738180-96fd-11ea-9668-a1711be664c2.JPG) 50 | - ex) 51 | - 교통 플랫폼 : 우버 - 차량 소유자와 이동필요한 수요자를 모바일 앱으로 연결 52 | - 모바일 메신저 플랫폼 : 카톡,라인 - 스마트폰 무료 메신저 서비스가 다양한 거래와 사업의 기반이 된다 53 | - 배달 플랫폼 : 배달의민족 - 배달음식점과 손님을 연결 54 | >[참고1](https://brunch.co.kr/@xhrkdl2000/3) 55 | >[참고2](https://subokim.wordpress.com/2013/01/31/platform-story/) 56 | 57 | ## 크롤링이란 ? 58 | - Web상에 존재하는 Contents를 수집하는 작업 59 | - HTML 페이지를 가져와서, HTML/CSS등을 파싱하고, 필요한 데이터만 추출하는 기법 60 | - Open API(Rest API)를 제공하는 서비스에 Open API를 호출해서, 받은 데이터 중 필요한 데이터만 추출하는 기법 61 | - Selenium등 브라우저를 프로그래밍으로 조작해서, 필요한 데이터만 추출하는 기법 62 | 63 |
64 | - java에서는 Jsoup(제이숩), Selenium(셀레니움)을 사용할수있다. 65 | 66 | |Jsoup|Selenium| 67 | |--|--| 68 | | 정적웹페이지 파싱시 적합 | 동적웹페이지 파싱시 적합| 69 | | client side rendering | server side rendering| 70 | | 빠른 응답 | (브라우저가 랜더링 된 후에 수집하기 때문)jsoup보단 느리다 | 71 | 72 | - 내 프로젝트는 동적페이지를 파싱하는것이 아니므로 jsoup을 사용했다. 73 | 74 | ```java 75 | String url1 = "https://devham76.com"; 76 | 77 | // 1. jsoup / html 태그 파싱필요 78 | Document doc = null; 79 | doc = Jsoup.connect(url1).get(); // HTML문서 가져온다 80 | 81 | // div의 id=underpins_ul인 li값들을 가져온다 82 | Elements elements = doc.select("div #underpins_ul li"); 83 | System.out.println(elements); 84 | 85 | // 그것들의 text만 가져온다 86 | String str = elements.text(); 87 | System.out.println(str); 88 | 89 | // 2. URL, openStream -> String으로 결과 90 | URL url2 = new URL(url1); 91 | BufferedReader br = new BufferedReader(new InputStreamReader(url2.openStream())); 92 | StringBuilder sourceCode = new StringBuilder(); 93 | 94 | String sourceLine; 95 | while ((sourceLine = br.readLine()) != null) { 96 | sourceCode.append(sourceLine + "\n"); 97 | } 98 | 99 | // 3. Selenium 100 | ``` 101 | 102 | 103 | ## Apache와 Nginx 104 | 105 | |Apahce | Nginx| 106 | |--|--| 107 | |요청당 쓰레드(or 프로세스)가 처리|비동기 이벤트 기반 요청을 처리 | 108 | |안정성 , 확장성, 호환성 | 성능 (대량접속에도 적은 리소스 사용, 빠르다)| 109 | |요청이 많을수록 cpu,메모리 사용증가로 인한
성능저하|적은 수의 쓰레드로 효율적인 일 처리, 문맥교환 비용적다
cpu 소모 적다 | 110 | 111 | **NGINX** 112 | - 트래픽이 많은 웹사이트를 위해 네트워크 확장성을 주목적으로 설계한 경량 http서버 113 | - 아파치 웹 서버를 대체할 대안으로 급부상 중 114 | - 비동기 이벤트 기반 구조 (아파치는 스레드/프로세스 기반) 115 | - 다수의 연결을 효과적으로 처리 116 | - 대부분의 코어 모듈이 Apache보다 적은 리소스로 더 빠르게 동작 117 | - 사용하는 곳 118 | - FaceBook, NetFlis, WordPress, GitHub 등 119 | - 네이버 첫페이지, 카카오톡 공지사항 서버 등 120 | 121 | **아파치 웹 서버** 122 | - 스레드/프로세스 기반 구조 123 | - client의 요청이 들어오면 스레드를 생성 124 | - 사용자가 많으면, 많은 스레드 생성 125 | - 메모리 및 CPU 낭비, Context-Swithcing Overhead발생 126 | 127 | ## Docker 128 | 1. 원하는 개발 환경을 도커파일에 저장하면, 도커는 원하는 어떤 머신에든 해당 환경을 제공 129 | - 다른 컴퓨터간 같은 이미지를 컨테이너화해서 같은 서버 환경 구축 가능 130 | 2. 이런 환경은 독립적으로 존재하기 때문에, 원하는 모든 환경을 모듈식으로 관리 가능 131 | - 하나의 같은 서버에서 각기 다른 컨테이너 설정가능(분리 , 독립) 132 | - 나에게 적용할수 있는점 133 | - AWS에서 1년간 무료로 저의 작은 서버를 사용하다가 무료 기간이 끝나면 다른 계정으로 옮겨서 무료로 사용하려고 하는데, 134 | - 서버 이전을 할 때 도커를 사용하면 손쉽게 환경을 세팅할수 있을것이다 135 | 136 | 137 | ## SSH(Secure Shell Protocol) 138 | - 컴퓨터끼리 public network를 통해 __안전하게 통신하기 위해 사용하는 프로토콜__ 139 | - 데이터 전송, 원격 제어 시 사용한다 140 | - private key, public key를 이용해 컴퓨터간 인증을한다 (서버와 클라이언트간 공개키,비밀키로 서로 인증 후, 대칭키 교환) 141 | 142 | 143 | ## HTTP1, HTTP2, HTTP3 144 | 145 | **HTTP** 146 | - 데이터 통신의 기초가 되는 응용프로그램 프로토콜 147 | - client/server모델을 기반으로한다 148 | - client가 server에게 요청하면 응답받는다 149 | 150 | ![HTTP1 2](https://user-images.githubusercontent.com/55946791/82141272-b8f3d200-986f-11ea-9d41-9ea70c1933d1.gif) 151 | 152 | **HTTP1.1** 153 | - 연결당 하나당 하나의 요청을 처리함 154 | - 동신전송 불가능, 요청과 응답 순차적으로 이뤄진다 155 | - 동시에 전송 문제와 다수의 리소스 처리하기에 속도와 성능이 좋지않다 156 | 157 | 158 | __문제점__ 159 | - RTT(Round Trip Time)증가 160 | - 하나의 연결에 하나의 요청을 처리한다 161 | - 요청별로 connection을 만들게 되고 3-way handshake가 반복적으로 일어나서 162 | - 불필요한 RTT증가와 네트워크 지연을 초래해서 성능을 저하시킨다. 163 | - 무거운 Header구조 (특히 cookie) 164 | - 헤더에 많은 메타 정보가 저장되어있다 165 | - 매 요청시 마다 중복된 헤더값을 전송하게 되며 166 | - domain에 설정된 cookie정보도 매 요청시 마다 헤더에 포함되어 전송되어 헤더값이 너무 무겁다 167 | - 해결을 위한 노력 168 | - image spriting : 웹 구성 이미지 파일 요청수를 줄이기 위해 아이콘을 하나의 큰 이미지로 만듬 169 | - domain sharding : 다수의 connection 을 생성, 병렬로 요청 보내기도한다 / 하지만 도메인별 커넥션 개수 제한 170 | - __SPDY__ : HTTP를 통해 전송을 재 정의하는 형태 171 | ![spdy](https://user-images.githubusercontent.com/55946791/82141687-88616780-9872-11ea-87d7-8611e1799ce8.png) 172 | - Multiplexing : 하나의 커넥션 안에서 다수의 독립적인 스트림을 동시에 처리 173 | - Server Push : 클라이언트 요청 없이 서버에서 콘텐츠를 직접 push가능 174 | - HTTP헤더 압축 175 | > [SPDY 참고](https://www.slideshare.net/oddpoet/spdy-13231459) 176 | 177 | **HTTP2** 178 | 179 | - 멀티플렉싱 요청 180 | ![http2](https://user-images.githubusercontent.com/55946791/82141520-53a0e080-9871-11ea-86c3-ff63fec1f3ce.png) 181 | - 동시에 여러개의 메세지를 동시에 주고 받을 수 있음 182 | - 응답은 순서 x 183 | - __단일 TCP 연결을 통해 여러 데이터 요청을 병렬로__ 보낼 수 있다. (웹 사이트를 빠르게 로드 할수있다) 184 | - 요청 헤더 압축 185 | 186 | > 187 | 188 | > [HTTP3](https://evan-moon.github.io/2019/10/08/what-is-http3/) 189 | -------------------------------------------------------------------------------- /contents/experience.md: -------------------------------------------------------------------------------- 1 | # 11. Experience 2 | **:book: Contents** 3 | * 어떤 역할을 맡았고, 무슨 기술을 썼으며, 어떤 어려움이 있었고 어떻게 해결했는지 4 | * 작성한 프로젝트의 보안은 어떻게 신경썼나요? 5 | * 코딩테스트문제에서 뭐가 인상깊거나 아쉬웠는지 간단히 6 | * 어떤 실패를 했고 어떻게 극복했고 어떤것을 얻었는지 7 | * 대용량 데이터 처리를 위한 서비스 아키텍처에 대해 설명해 주세요. 그에 대한 기술도 함께 말씀해 주세요. 8 | * 무슨과목좋아하는지 9 | * 챗봇은 어떤엔진으로 구축햇는지 10 | * 우리회사에서 뭐하고싶은지 11 | * 알림톡데몬 유지보수 12 | * 개발이좋은지 유지하는게좋은지? 13 | * 전산이 적성에맞는지 14 | 15 | * 저희 회사에 대해 궁금한건 질문 해보세요 16 | --- 17 | ## 어떤 역할을 맡았고, 무슨 기술을 썼으며, 어떤 어려움이 있었고 어떻게 해결했는지 18 | 19 | ### 1. 알림톡 20 | ### 2. 챗봇 21 | ### 3. 개인플젝 - 스프링 프로젝트 22 | 23 | ### JAVA 크롤링 24 | 25 | **서버 사이드 랜더링** 26 | - 화면이 어떻게 보여질지 서버측에서 html+view를 생성하여 응답하는 방법 27 | - 즉, server에서 view생성 28 | 29 | **클라이언트 랜더링(CSR)** 30 | - 요즘 사용하는 방법 31 | - 서버측에서 하나의 빈 페이지 & 데이터 전송 32 | - client(브라우저)는 데이터를 가지고 자바스크립트를 통해 랜더링 한다 33 | - 즉, client에서 view생성 34 | 35 | **java 크롤링** 36 | - __jsoup__ 37 | - CSR을 한다면, server에 HTTP를 요청하므로 실제 화면에 그려진 데이터를 수집할수없다 38 | - 따라서 __SSR__을 하는 server에만 크롤링 가능하다 39 | - jsoup을 이용해 get방식으로 html을 가져오고, document 객체를 이용해서 html태그를 파싱했다/ 40 | - __selenium__ 41 | - 동적페이지도 처리 가능하다 42 | 43 | ### 저희 회사에 대해 궁금한거 질문 해보세요 44 | - 자랑할만한 개발문화가 있나요? 45 | - 신입개발자를 위한 스터디가 있나요? 46 | - 개발책이나 교육 비용 지원해주나요? 47 | - 신규개발을 많이 하게 되나요?아니면, 기존 서비스를 유지보수하는일을 많이 하게되나요? 48 | - 신입 개발자에게 가장 중요한 부분은 어떤거라고 생각하시나요? 개발실력, CS기본기, 개발경험, 인성 어떤 부분인지 49 | - L사 기술 컨퍼런스는 매년하나요? 50 | - L사 외국 개발자들과 협업하는건 어렵지않나요? 언어나 문화적 차이 어떤지 궁금합니다 51 | -------------------------------------------------------------------------------- /contents/java.md: -------------------------------------------------------------------------------- 1 | # 7. Java 2 | **:book: Contents** 3 | * [자바 컴파일 과정을 설명하라](#자바-컴파일-과정을-설명하라) 4 | * [String, StringBuffer, StringBuilder의 차이점에 대해 설명하라](#String,StringBuffer,StringBuilder) 5 | * [OOP의 4가지 특징](#OOP의-4가지-특징) 6 | * [오버로딩과 오버라이딩의 차이](#오버로딩과-오버라이딩의-차이) 7 | * [HashMap과 TreeMap의 차이](#HashMap과-TreeMap의-차이) 8 | --- 9 | * [GC에 대해 설명하라](#GC에-대해-설명하라) 10 | * [자바의 메모리구조](#자바의-메모리구조) 11 | * [동등성(equals)과 동일성(==)](#equals,==) 12 | * [제네릭과 와일드카드](#제네릭과-와일드카드) 13 | * [멀티스레딩환경에서 동기화문제를 해결하는 방법에대해 설명하라 (syncronized, atomic, volatile)](#멀티스레딩환경에서-동기화문제를-해결하는-방법) 14 | 15 | --- 16 | * java의 접근 제어자의 종류와 특징 설명해주세요 17 | * 멤버 변수 & 지역 변수 18 | * non-static 멤버와 static멤버의 차이 설명해주세요 19 | * final 키워드 (final/finally/finalize) 설명해주세요 20 | * 인터페이스와 추상 클래스의 차이(Interface vs Abstract Class) 설명해주세요 21 | * set, list, map의 차이와 각각의 인터페이스 구현체의 종류를 설명해주세요 22 | 23 | * Comparable, Comparator 차이 24 | 25 | --- 26 | * [java8을 써보셨나요? java7에서 8로 올라오면서 어떤게 달라졌나요?](#java8을-써보셨나요?-java7에서-8로-올라오면서-어떤게-달라졌나요?) 27 | * [this 키워드](#this-키워드) 28 | * [자바에서 tcp udp 소켓 생성 방법](#자바에서-tcp-udp-소켓-생성-방법) 29 | * [리틀엔디안 빅엔디안](#리틀엔디안-빅엔디안) 30 | * [Reflection](#Reflection) 31 | * [oop 5대 원칙](#oop-5대-원칙) 32 | * [직렬화란?](#직렬화란?) 33 | 34 | --- 35 | --- 36 | ## 자바 컴파일 과정을 설명하라 37 | ![jvm구조](https://user-images.githubusercontent.com/55946791/80935310-02bbd180-8e07-11ea-8723-b1f09125e26c.jpg) 38 | 39 | 1. .java 파일을 build하면 Java Compiler의 javac라는 명령어를 사용해서 .class파일을 생성한다 40 | (.class파일은 byte code로 아직 컴퓨터가 읽을 수 없는 반기계어 이다.) 41 | 3. .class파일은 Class Loader에 의해서 JVM내로 로드 된다. 42 | 4. 실행엔진(인터프리터 또는 JIt)을 이용해서 byte code-> binary code로 변환한다. 43 | 5. 변환된 binary code(기계어)는 메모리에(Runtime Data Area) 배치된다. 44 | 6. Runtime Data Area에 올라간 파일은 실행엔진(Execution Engine)에 의해 실행 45 | - 이와 같은 과정을 통해 Java파일이 컴파일되고, JVM에 의해 해당 OS에 맞게 변환시커 컴퓨터가 읽을 수 있도록 만들어준다. 46 | 47 | **실행 엔진 종류** 48 | - Interpreter : 자바 byte code를 한줄 씩 실행. 속도 느림 49 | - JIT Compiler : (Just In Time)Interpreter의 단점을 보완. 50 | 전체 byte code를 컴파일, 속도가 느리지만 캐시를 사용해서 51 | 한번 컴파일 하면 다음에는 빠르게 수행된다. 52 | 53 | 54 | > - 55 | > - 56 | > - 57 | 58 | **jvm** 59 | JVM은 Java Byte Code를 OS에 맞게 해석해주는 역활 60 | 61 | **JRE** 62 | - 자바 클래스 라이브러리(Java class libraries) + 63 | 자바 클래스 로더(Java class loader) + 64 | 자바 가상 머신(Java Virtual Machine) 65 | >[참고](http://www.itworld.co.kr/news/110768) 66 | 67 | > :arrow_double_up:[Top](#7-java) :leftwards_arrow_with_hook:[Back](https://github.com/devham76/tech-interview-studyw#7-java) :information_source:[Home](https://github.com/devham76/tech-intervie-studyw#tech-interview) 68 | 69 | ## String,StringBuffer,StringBuilder 70 | 71 | **공통점** 72 | String을 저장하고 관리하는 클래스 73 | 74 | **차이점** 75 | immutable(불변) : String 76 | mutable(가변) : StringBuffer, StringBuilder 77 | 78 | **String** 79 | - 리터럴을 통해 생성되면, 그 인스턴스의 메모리 공간은 절대 변하지 않는다 80 | 81 | ```java 82 | String str = "literal" // 리터럴로 생성하는 방식 83 | ``` 84 | 85 | - 문자열 변수에 변화를 주면, 메모리 공간 내의 값이 변하는 것이 아니라 86 | __String Pool이라는 공간안에 메모리를 할당 받아 새로운 String 클래스 객체를__ 만들어서 87 | 문자열을 나타낸다. 88 | - 따라서 변화가 나타날때마다 89 | 1. 기존 문자열은 가비지 콜렉터에 의해 제거되야 하고 90 | 2. 계속해서 문자열 객체를 만드는 오버헤드가 발생해서 성능이 떨어진다. 91 | 92 | **String 클래스가 적절한 경우** 93 | - String클래스는 문자열 연산이 적고, 자주 조회하는 경우 사용하면 좋다. 94 | - 멀티쓰레드 환경 95 | 96 | **StringBuffer vs StringBuilder** 97 | - String과 다르게 문자열 연산시, 클래스는 한번만 만들고(new), 메모리의 값을 변경시켜서 문자열을 변경한다. 98 | 99 | **StringBuffer** 100 | - 멀티 쓰레드 환경에서 동기화 O, 즉 thread-safe하다 101 | - 내부적으로 append 등 모든 메소드에 대해 synchronized 키워드가 붙어있다. 102 | 103 | **StringBuilder** 104 | - 동기화 X 105 | - 싱글 쓰레드 환경에서 StringBuffer에 비해 연산처리가 빠르다. 106 | 107 | > 108 | 109 | --- 110 | # String vs StringBuilder 111 | 112 | ## String 113 | - String 클래스는 불변 114 | - 문자열은 한 번 생성 되면, 메모리 내부에서 변경 불가능 115 | - __연산 과정__ : 메모리 내에서 이전과 다른 __새로운 문자열이 새롭게__ 만들어진다 (string pool에) 116 | - 연산 후 기존의 문자열 객체는 더이상 참조되지 않기 때문에 GC의 대상이 된다 117 | - 따라서, 연산이 여러번 반복 실행되면, 메모리 낭비와 불필요한 액션이 발생하게 된다 118 | - + , concat() / 그중에서도 +는 속도가 훨씬 느리다 119 | ![string1](https://user-images.githubusercontent.com/55946791/83489455-5fcfa380-a4e9-11ea-9df0-6da9aa9de163.png) 120 | ![String_Perf_Chart_28](https://user-images.githubusercontent.com/55946791/83489629-aae9b680-a4e9-11ea-821a-ed0e211dcbba.png) 121 | 122 | 123 | ## StringBuilder 124 | - 이 클래스는 가변적 125 | - __연산 과정__ : 새로운 문자열 만들지X, __기조의 문자열에 추가,수정 될 뿐이다.__ 126 | - append() 127 | 128 | **내부 작동** 129 | - 가변 길이의 배열과 같이 작동 130 | - StringBuilder 객체가 생성되면, 일정크기(16)를 갖는 빈 문자열 객체가 생성된다 131 | - 여기에 사용자가 문자열을 대입하면 미리 준비된 배열 공간에 문자열이 들어간다 132 | 133 | 134 | ![stringbuilder1](https://user-images.githubusercontent.com/55946791/83489448-5f370d00-a4e9-11ea-9370-9f5274018fd4.png) 135 | 136 | 137 | > [StringBuilder 클래스에 대해서 알기!](https://m.blog.naver.com/itinstructor/100203105622) 138 | 139 | 140 | > :arrow_double_up:[Top](#7-java) :leftwards_arrow_with_hook:[Back](https://github.com/devham76/tech-interview-studyw#7-java) :information_source:[Home](https://github.com/devham76/tech-intervie-studyw#tech-interview) 141 | 142 | ## OOP의 4가지 특징 143 | 캡상추다 144 | 1. 캡슐화 145 | 특정 객체가 독립적으로 역할을 수행하기 위해 필요한 데이터와 기능을 하나로 묶은것.(모듈화) 146 | 객체 안의 정보에 직접 접근을 허용하지 않고 필요에 따라 확인할 수 있는 인터페이스를 외부에 공개한다.(은닉화) 147 | 148 | 2. 상속 149 | 상위 개념의 특징을 하위 개념이 물려받는 것 150 | 151 | 3. 추상화 152 | 객체들의 공통적인 특징(속성, 기능)을 모아 하나의 클래스로 다룬다 153 | 각 객체의 구체적인 개념에 의존하지 말고 추상적인 개념에 의존해야 설계를 유연하게 변경할 수 있다. 154 | 아우디 ->자동차 155 | 벤츠 -> 자동차 156 | 157 | 4. 다형성 158 | 하나의 타입으로 여러가지 참조변수를 사용할수 있는것 159 | 160 | > :arrow_double_up:[Top](#7-java) :leftwards_arrow_with_hook:[Back](https://github.com/devham76/tech-interview-studyw#7-java) :information_source:[Home](https://github.com/devham76/tech-intervie-studyw#tech-interview) 161 | 162 | ## 오버로딩과 오버라이딩의 차이 163 | **Overloading** 164 | - 개념 165 | 하나의 클래스에서 같은 이름의 메소드를 여러 개 가질 수 있다. 166 | 단, 메서드의 파라메터 값은 달라야 한다. (반환 타입은 같아도,달라도 된다.) 167 | - 오버라이딩은 왜 있는지? 168 | 유사한 일을 수행하면서 인자마 다른 메소드들을 각기 다른 이름으로 준다면 불편. 169 | ex) 키보드를 문서용 키보드 , 게임용 키보드를 따로 만들면 비효율적이다. 170 | 171 | **Overridng** 172 | - 개념 173 | 슈퍼클래스를 상속받은 서브 클래스에서 슈퍼 클래스의 메소드를 같은 이름, 같은 반환값, 174 | 같은 인자로 메소드 내의 로직들을 새롭게 정의 하는 것. 175 | 오버라이딩을 이용해서 같은 이름이지만 구현하는 클래스마다 다른 역할을 하는 메소드를 정의한다 176 | ex) 키보드라는 모양을 가졌지만, 문서를 작성하고 게임을 한다. 177 | 178 | > 179 | 180 | > :arrow_double_up:[Top](#7-java) :leftwards_arrow_with_hook:[Back](https://github.com/devham76/tech-interview-studyw#7-java) :information_source:[Home](https://github.com/devham76/tech-intervie-studyw#tech-interview) 181 | 182 | ## HashMap과 TreeMap의 차이 183 | **Map** 184 | - key와 value를 가진 집합으로, 중복허용X 185 | 186 | |기능 | HashTable| HashMap| ConcurrentHashMap| 187 | |--|--|--|--| 188 | |key, value null허용여부| X | O | X | 189 | | 여러 쓰레드 안전 여부 | O
(put,get과 같은 주요 메서드에 syncronized 키워드가 선언되어있다)| X | O (map전체에 lock을걸지않는다 부분적으로 걸기 때문에 더 효율이 좋다)| 190 | 191 | **참고) vector vs arrayList** 192 | - vector는 무조건 동기화를 지원하기 때문에 멀티프로세싱이 아닌 프로그램에서 사용하면 효율이 떨어진다 193 | 194 | >[참고](https://jdm.kr/blog/197) 195 | 196 | 197 | 198 | | HashMap| TreeMap| 199 | |--|--| 200 | | 순서 유지 x | key값에 따라 정렬| 201 | | Hashing으로 내부 구현 | Red-Black 트리로 내부 구현| 202 | |key: null 1개 허용, value:허용 | key: null 허용x, value:허용| 203 | | O(1) get,put 같은 기본 연산에 일정한 시간 성능 | O(log n) 시간 204 | | treemap보다 빠르다 | hashmap보다 느리다| 205 | |Map 인터페이스 구현| NavigableMap 인터페이스 구현| 206 | 207 | > 208 | 209 | > :arrow_double_up:[Top](#7-java) :leftwards_arrow_with_hook:[Back](https://github.com/devham76/tech-interview-studyw#7-java) :information_source:[Home](https://github.com/devham76/tech-intervie-studyw#tech-interview) 210 | 211 | 212 | ## GC에 대해 설명하라 ★★★★ 213 | (조금더 깊게) 214 | 215 | - Heap 메모리 영역에 적재된 객체의 생존 여부를 판단하여 더 이상 사용되지 않는(참조 되지 않는) 객체를 해제하는 방식으로 메모리를 자동 관리한다. 216 | 217 | - 참조 루트로부터 더이상 참조할수없을때는 218 | 참조성을 따져서 강한참조는 해제안되고 219 | 약한 참조는 해제될수있다 220 | 메모리가 부족하면 해제될수있다. (자바의 참조성) 221 | - 참조성 (강한참조, 약한참조..) 222 | - 두 객체끼리 강한참조이면 해제된다. 참조루트로부터 참조될수없으면 해제된다 223 | 224 | 225 | - GC가 제거하는 시간은 정확히 언제인지 모른다. (참조가 없어지자마자 해제 되지않는다) 226 | - GC가 수행되는 동안 GC를 수행하는 쓰레드가 아닌 __다른 모든 쓰레드는 일시정지__ 227 | - 특히 Full GC가 일어나서 수 초간 모든 쓰레드가 정지한다면 장애로 이어지는 치명적인 문제 발생가능 228 |
229 | 230 | **Heap영역은 GC의 주요 대상** 231 | - 구현원리 , 객체들이 한번 참조되면 232 | - 처음에 에덴에 생성이 되고, .....(조사할것) 233 | - __Young Generation__ 234 | - 이 영역은 자바 객체가 생성되자마자 저장되고, 생긴지 얼마 안되는 객체가 저장되는 공간이다. 시간이 지나 우선순위가 낮아지면 Old 영역으로 옮겨진다. 이 영역에서 객체가 사라질 때 Minor GC가 발생한다. 235 | - __Old(Tenured) Generation__ 236 | - Young Generation 영역에서 저장되었던 객체 중에 오래된 객체가 이동되어 저장되는 영역이다. 이 영역에서 객체가 사라질 때 Major GC(Full GC)가 발생한다. 237 | 238 | 239 | > 240 | > - [참고1](https://jeong-pro.tistory.com/148) 241 | > - [참고2](https://hoonmaro.tistory.com/19) 242 | 243 |
244 | **GC** 245 | - C++에서 new나 delete를 통해 메모리를 명시적으로 해제했지만 Java에서는 개발자가 프로그램 코드로 메모리를 명시적으로 해제하지 않고 가비지 컬렉터(Garbage Collector)가 이 역할을 대신한다. 더 이상 사용하지 않는 객체를 찾아서 지우는 역할을 하는것이 GC 이다. 246 |

247 | Garbage Collection을 실행하면 JVM이 일시적으로 어플리케이션 실행을 멈추는데 이를 stop-the-world 라 한다. 248 |

249 | stop-the-world가 발생하면 GC를 실행하는 쓰레드를 제외한 나머지 쓰레드는 모두 작업을 멈춘다. GC 작업을 완료한 이후에야 중단했던 작업을 다시 시작한다. 어떤 GC 알고리즘을 사용하더라도 stop-the-world는 발생한다. 대개의 경우 GC 튜닝이란 이 stop-the-world 시간을 줄이는 것이다. 250 |

251 | GC는 아래의 두가지 가설을 토대로 만들어졌다. 252 |

253 | 대부분의 객체는 금방 접근 불가능 상태(unreachable)가 된다. 254 | 오래된 객체에서 젊은 객체로의 참조는 아주 적게 존재한다. 255 | 이러한 가설을 ‘weak generational hypothesis’라 한다. 이 가설의 장점을 최대한 살리기 위해서 HotSpot VM에서는 크게 2개로 물리적 공간을 나누었다. 둘로 나눈 공간이 Young 영역과 Old 영역이다. 256 |

257 | 영역별 데이터 흐름은 아래와 같다. 258 | 259 | ![helloworld-1329-1](https://user-images.githubusercontent.com/55946791/81578490-d6471d00-93e5-11ea-9987-8b56a33d7817.png) 260 | 261 |

262 | 위의 Permanenet Generation 영역은 Method 영역에 포함된 부분이고.. Java 8부터 MetaSpace 영역으로 바뀌었다고 한다(PermGen 영역에서 일어나는 GC도 Major GC에 포함된다.) 263 |

264 | 265 | **Young 영역** 266 | - 새롭게 생성된 데이터 대부분이 Young Generation에 위치하며 여기서 객체가 할당 해제되는 경우 __Minor GC가__ 발생했다고 한다. 267 | - Eden 영역 268 | - Survivor 영역(2개) 269 | - 으로 나뉘며, Eden에서 살아남은 객체는 Survivor 으로 보내고, Survivor영역이 가득 차면 다른 Survivor 영역으로 보낸다. 이 과정에서 살아남은 객체는 Old 영역으로 이동하게 된다. 270 | 271 | 272 | **Old 영역** 273 | 접근 불가능 상태로 되지 않아 Young 영역에서 살아남은 객체가 여기로 복사된다. 대부분 Young 영역보다 크게 할당하며, 크기가 큰 만큼 Young 영역보다 GC는 적게 발생한다. 여기서 객체가 할당 해제되는 경우 __Major GC가__ 발생했다고 한다. 274 |

275 | Old 영역은 기본적으로 데이터가 가득 차면 GC를 실행한다. 276 |

277 | Major GC는 아래와 같은 방식에 따라 동작한다. GC 방식에 따라 처리가 달라진다. 278 | - Serial GC 279 | - Parallel GC 280 | - Parallel Old GC(Parallel Compacting GC) 281 | - Concurrent Mark & Sweep GC(이하 CMS) Java 9 부터 삭제. 282 | - G1(Garbage First) GC 283 | 284 | >[참고](https://tramyu.github.io/etc/interview/) 285 | 286 | > :arrow_double_up:[Top](#7-java) :leftwards_arrow_with_hook:[Back](https://github.com/devham76/tech-interview-studyw#7-java) :information_source:[Home](https://github.com/devham76/tech-intervie-studyw#tech-interview) 287 | 288 | ## 자바의 메모리구조 289 | ![jvm 메모리 구조](https://user-images.githubusercontent.com/55946791/81367024-0f059e80-9127-11ea-9159-2e7efe749983.png) 290 | 291 | **Method area(메소드 or 스테틱 영역)** 292 | - __모든 스레드가 공유하는 영역으로 JVM이 시작될 때 생성, 프로그램 종료시 해제.__ 293 | - __static변수, final class변수__ 등이 생성 294 | - JVM이 읽어 들인 각각의 클래스와 인터페이스에 대한 런타임 상수 풀, 필드와 메서드 정보, static 변수, 메서드의 바이트코드 등을 보관한다. 295 | - class의 구조 정보가 들어간다. 296 | 297 | - 멤버변수(static), 데이터 타입, 접근제어자 같은 필드 정보 298 | - 메소드 이름, 리턴 타입, 파라메터, 접근 제어자 같은 __메소드 정보__ 299 | - type정보 (interface or class), Constant Pool(상수 풀: 문자 상수, 타입, 필드, 객체참조) 300 | 301 | **Runtime Constant Pool** 302 | - 각 클래스와 인터페이스의 상수뿐만 아니라, 메서드와 필드에 대한 모든 레퍼런스까지 담고 있는 테이블이다. 303 | - 즉, 어떤 메서드나 필드를 참조할 때 JVM은 런타임 상수 풀을 통해 해당 메서드나 필드의 실제 메모리상 주소를 찾아서 참조한다. 304 | 305 | **Heap area** 306 | - __new 키워드로 생성된 객체와 배열을__ 저장 307 | - 메소드 영역에 로드된 클래스만 생성가능하다 308 | - 데이터가 동적으로 생성, 소멸 309 | - 참조하는 변수나 필드가 없으면 의미 없는 객체가 되어 __GC의 대상이 된다__ 310 | 311 | 312 | **Perm 영역** 313 | ![java 78 heap](https://user-images.githubusercontent.com/55946791/82112736-bec3b780-978a-11ea-98e7-eafc2d9713a6.jpg) 314 | - JDK __8부터 Permanent Heap 영역이 제거되었다.__ 315 | - 대신 Metaspace 영역이 추가되었다. 316 | - __Perm은 JVM에 의해 크기가 강제되던__ 영역이다. 317 | - __Metaspace는 Native memory 영역으로, OS가 자동으로 크기를 조절한다.__ 318 | - 옵션으로 Metaspace의 크기를 줄일 수도 있다. 319 | - 그 결과 기존과 비교해 __큰 메모리 영역을 사용할 수__ 있게 되었다. 320 | - Perm 영역 크기로 인한 __java.lang.OutOfMemoryError를 더 보기 힘들어진다__ 321 | - 저장 정보 : Class의 Meta 정보, Method의 Meta 정보, Static 변수와 상수 정보들이 저장 -> java8 ( Static Object는 Heap 영역으로 옮겨져서 GC의 대상) 322 | 323 | 324 | > 325 | 326 | **Stack area** 327 | - 지역변수, 파라메터, 리턴 값, 연산에 사용되는 임시 값이 생성되는 영역 328 | - Method정보, 메소드 호출 시 사용하는 지역변수 데이터 등을 저장한다. {}가 끝나는 동안 유지된다. 329 | 330 | - __기본(원시)타입 변수는 스택영역에 직접 값을 가진다__ 331 | - ex) int a = 10; 스택영역에 이름이a인 공간 생성, 10입력 332 | - __참조타입 변수는 힙 영역이나 메소드 영역의 객체 주소를 가진다__ 333 | - ex) Person p = new Person(); Person p는 스택에 생성, new로 생성된 인스턴스는 heap에 생성 334 | - 스택에 생성된 p값으로 heap영역에 생성된 객체 참조한다(가르킨다) 335 | - 각 쓰레드 마다 존재, 쓰레드가 시작될때 할당. 336 | 337 | 338 | **PC 레지스터** 339 | - 쓰레드가 생성될때마다 생성되는 영역 340 | - 현재 쓰레드가 실행되는 부분의 __주소와 명령을 저장__ 하고 있다. 341 | - 이것을 이용해서 쓰레드를 돌아가면서 수행할 수 있다. 342 | - 스레드가 시작 될 때 생성, 현재 수행중인 JVM의 명령의 주소를 가진다. 343 | 344 | **Native Method Stack** 345 | - 자바 외 언어로 작성된 네이티브 코드를 위한 메모리 영역 346 | - 보통 c/c++등의 코드를 수행하기 위한 스택 347 | 348 | **쓰레드가 생성되었을 때** 349 | - method, heap : 모든 쓰레드가 공유 350 | - stack, pc레지스터, native method stack : 각각의 쓰레드마다 생성, 공유x 351 | 352 | 353 | ![jvm 메모리](https://user-images.githubusercontent.com/55946791/83709315-359cf380-a659-11ea-8c16-dfa474482873.png) 354 | 355 | 356 | > [참고1](https://hoonmaro.tistory.com/19) 357 | > [참고2](https://jeong-pro.tistory.com/148) 358 | > [참고3](https://steady-snail.tistory.com/67) 359 | 360 | ## equals,== 361 | 362 | - equals() 는 객채간의 __내용(값)을__ 비교할 수 있는 __'메소드'__ 입니다. 363 | 364 | - ==는 객체의 __참조(주소)값을__ 비교하는 __'연산자'__ 입니다. 365 | 366 | > [참고](https://ojava.tistory.com/15) 367 | 368 | > :arrow_double_up:[Top](#7-java) :leftwards_arrow_with_hook:[Back](https://github.com/devham76/tech-interview-studyw#7-java) :information_source:[Home](https://github.com/devham76/tech-intervie-studyw#tech-interview) 369 | 370 | ## 제네릭과 와일드카드 371 | 372 | **Generics(제네릭스)** 373 | 374 | - __클래스를 선언할 때 타입을 결정하지X 객체를 생성할 때 유동적인 타입으로 재사용하기 위한 것__ 375 | 376 | - 형변환을 할 필요없고, 타입 에러가 발생할 확률이 없어진다. 377 | 378 | - 타입추론은 메서드를 호출하는 코드에서 타입인자가 정의한대로 제대로 쓰였는지 살펴보는 컴파일러의 능력이다. 379 | 380 | 381 | - __다양한 타입의 객체들을 다루는 메서드나 컬렉션 클래스에 컴파일시에 타입체크를 해주는 기능__ 382 | - __컴파일 후에__ 지네릭 타입이 제거 되고 __원시 타입으로 지정된다.__ (.class파일에는 지네릭 타입에 대한 정보가 없다.) 383 | 384 | 385 | 386 | **Generics 장점** 387 | - 타입의 안정성 제공 (의도하지 않은 타입의 객체가 저장되는 것을 막고, 저장된 객체를 꺼내올 때 원래의 타입과 다른 타입으로 잘못 형변환되어 발생하는 오류를 막는다.) 388 | - 타입체크와 형변환을 생략하여 코드가 간결해진다. 389 | - ex) ArrayList는 다양한 종류의 객체를 담는다. 보통 한 종류의 객체를 담는다. 꺼낼 때마다 타입체크를 하고 형변화 하는 것은 불편하다. 390 | 391 | 392 | 393 | 394 | **컬렉션(collection) 클래스에서 제네릭을 사용하는 이유를 설명하시오.** 395 | 396 | - 컬렉션 클래스에서 제네릭을 사용하면 컴파일러는 __특정 타입만 포함 될 수 있도록 컬렉션을 제한__ 합니다. 397 | - ex) ArrayList list : ArrayList에는 int 타입만 입력 가능하다 398 | 399 | - 컬렉션 클래스에 저장하는 인스턴스 타입을 제한하여 __런타임에 발생할 수 있는 잠재적인 모든 예외를 컴파일타임에__ 잡아낼 수 있도록 도와줍니다. 400 | 401 | 402 | **Generics 주의할 점** 403 | - __static멤버에 타입변수 T를 사용x__ 404 | - why? static멤버는 타입 변수에 지정된 타입, 즉 대입된 타입의 종류에 관계없이 동일한 것이어야 하기 때문이다. 405 | - Box.item과 Box.item이 다른것이면 안된다는 뜻. 406 | - 참조변수와 생성자에 대입된 타입이 일치해야한다 407 | - ex) 408 | 409 | ```java 410 | Box appleBox = new Box(); // o 411 | Box appleBox = new Box(); // x 412 | Box appleBox = new Box(); // x 413 | Box appleBox = new FruitBox() // o (다형성) 414 | ``` 415 | 416 | **제한된 Generics** 417 | - 지네릭 타입에 __extends__ 를사용하면, __특정 타입의 자손들만__ 대입할 수 있다. 418 | - ex. 419 | 420 | ```java 421 | // Fruit의 자손만 타입으로 지정가능 422 | class FruitBox{ 423 | ArrayList list = new ArrayList(); 424 | } 425 | FruitBox appleBox = new FruitBox(); // o 426 | FruitBox toyBox = new FruitBox(); // x 427 | 428 | FruitBox fruitBox = new FruitBox(); 429 | fruitBox.add(new Apple()); // o, apple은 Fruit의 자손 430 | fruitBox.add(new Orange());// o, orange는 Fruit의 자손 431 | ``` 432 | 433 | - 만일 클래스가 아니라 인터페이스를 구현해야 한다는 제약이 필요하면 __extends__ 를 사용한다. (implemetns아니다!) 434 | - ex. 435 | 436 | ```java 437 | interface Eatable {} 438 | class FruitBox {...} 439 | ``` 440 | 441 | 442 | **와일드 카드** 443 | - 특정 타입을 지정할때 제한을 둘 수 있다. 444 | 445 | ``` 446 | : 와일드 카드의 상한 제한, T와 그 자손들만 가능 447 | : 와일드 카드의 하한 제한, T와 그 조상들만 가능 448 | : 제한 없음. 모든 타입가능 와 동일 449 | ``` 450 | 451 | > [참고 - Java의 정석] 452 | 453 | > :arrow_double_up:[Top](#7-java) :leftwards_arrow_with_hook:[Back](https://github.com/devham76/tech-interview-studyw#7-java) :information_source:[Home](https://github.com/devham76/tech-intervie-studyw#tech-interview) 454 | 455 | ## 멀티스레딩환경에서 동기화문제를 해결하는 방법 456 | - synchronized, atomic, volatile 457 | 458 | **멀티스레딩** 459 | - 멀티 스레드(multi thread)란? _하나의 프로세스 내에서 둘 이상의 스레드가 동시에 작업을 수행_ 하는 것 460 | - 멀티스레드 프로그램은 __공유하는 자원__ 에 대해 동기화 문제가 발생할 수 있다. 461 | - method area, heap area는 스레드가 공유하는 영역이다. 462 | 463 | **멀티스레드 사용이유** 464 | - 멀티 스레드는 각 스레드가 자신이 속한 프로세스의 메모리를 공유하므로, 시스템 __자원의 낭비가 적습니다.__ 465 | - 하나의 스레드가 작업을 할 때 다른 스레드가 별도의 작업을 할 수 있어 __사용자와의 응답성도 좋아집니다.__ 466 | 467 | **Synchronized** 468 | - 자바에서 지원하는 Synchronized키워드는 __현재 데이터를 사용하고 있는 쓰레드를 제외하고 나머지 쓰레드는 데이터에 접근할 수 없도록 막는 개념__ 469 | - Synchroinzed 키워드를 너무 __남발하면 오히려 프로그램 성능저하 발생__ 470 | - Synchroinzed 키워드를 사용하면 자바 내부적으로 메서드나 변수에 동기화를 위해 block, unblock처리하는데 471 | - 이런 처리가 너무 많아지면 성능저하 발생 472 | 473 | **Synchronized 방법** 474 | 1. 메소드 전체를 임계 영역으로 지정 475 | - 함수에 lock을 거는 것처럼 보이지만, 실제로는 객체에 lock을 건다. 476 | - 즉, synchronized 함수는 자신이 포함된 객체에 lock을 건다. 이 방법은 간단하지만 객체에 포함된 다른 것들도 lock이 걸리기 때문에 무식한 방법이기도 하다. 477 | - _메서드 전체에 걸기보다 synchronized블러으로 임계 영역을 최소화 하는것이 좋다_ 478 | 479 | - static 함수에 걸면 class전체에 lock이 걸린다 480 | ```java 481 | public synchronized void fun(String param) { 482 | // 동기화 하고싶은 코드 483 | } 484 | ``` 485 | 486 | 2. 특정 영역을 임계 영역으로 지정 487 | - 필요한 부분에만 동기화처리를 하고, 동기화가 필요없는 부분은 lock을 걸지않고 그대로 둘 수 있다. 488 | - 이때 obj(객체 참조변수)는 lock의 주체이기 때문에 obj가 락을 풀때까지 다른 블록들은 대기 489 | 490 | ```java 491 | private Object obj = new Object(); 492 | public void exampleMethod(){ 493 | synchronized(obj){ 494 | // 동기화 하고싶은 코드 495 | } 496 | } 497 | ``` 498 | 499 | **Atomic** 500 | - lock이나 synchronized없이도 결과의 안정성을 보장받을 수 있는 것을 __원자적(Atomic)__ 이라고 하고, 501 | - 자바의 concurrent 패키지에서 이를 제공한다. 502 |
503 | 504 | - AtomicInter 클래스는 __CAS(compare-and-swap)__ 기반으로 되어있다. 505 | - CAS는 특정 메모리 위치와 주어진 위치의 value를 비교하여 다르면 대체하지 않는다. 506 | - 이 방법은 저수준의 H/W에서 제공한다. 507 | 508 | ```java 509 | private AtomicInteger c = new AtomicInteger(); 510 | 511 | public int getNextIndex(){ 512 | return c.getAndIncrement(); 513 | } 514 | ``` 515 | 516 | **Volatile** 517 |
518 | - atomic안에 volatile이 구현되어있다 519 | _[자바의 정석 설명]_ 520 | - 멀테 코어 프로세서가 장착된 컴퓨터에서, 코어마다 별도의 캐시를 가질때 문제가 발생할수있다. 521 | - 코어는 메모리에서 읽어온 값을 캐시에 저장하고 캐시에서 값을 읽어 작업한다. 522 | - 다시 같은 값을 읽어올 때는 먼저 캐시에 있는지 확인하고 없을 때만 메모리에서 읽어온다. 523 | - 그러다 보니 도중에 메모리에 저장된 변수의 값이 변경 되었는데도 , 캐시에 저장된 값이 갱신되지 않아 메모리에 저장된 값이 다른 경우가 발생한다. 524 |
525 | - 따라서 변수 앞에 volatile을 붙이면, 코어가 변수의 값을 읽어올때 캐시가 아닌 메모리에서 읽어오기 때문에 캐시와 메모리간의 값의 불일치가 해결된다. 526 |

527 | 528 | _[인터넷 블로그 설명]_ 529 | - 자바 변수에 volatile을 붙이면 volatile 변수를 읽어 들일 때 __cpu캐시가 아니라 컴퓨터의 메인 메모리에서 읽는다___ 530 | - volatile 키워드는 __가시성__ 문제를 해결해준다. 531 | - 가시성 문제란? 멀테 쓰레드 환경에서 메인 메모리로 아직 기록하지 않은 값을 보지 못하여 동기화가 깨진 상황을 말한다 532 | - volatile을 써야 하는 경우는 한 쓰레드에서 변수의 값을 읽고 쓰며, 다른 쓰레드에서 읽기만 하는 경우 항상 value를 보장해줄수있다 533 | - 그러지 않고 멀티 쓰레드가 value를 변경한다면 synchronization을 적용해야 한다 534 | 535 | ```java 536 | public class Foo { 537 | public volatile int c = 0; 538 | } 539 | ``` 540 | 541 | >[참고](https://doll6777.github.io/android/2019/07/10/synchronized/) 542 | 543 | > :arrow_double_up:[Top](#7-java) :leftwards_arrow_with_hook:[Back](https://github.com/devham76/tech-interview-studyw#7-java) :information_source:[Home](https://github.com/devham76/tech-intervie-studyw#tech-interview) 544 | 545 | 546 | ## java의 접근 제어자의 종류와 특징 설명해주세요 547 | ![접근 제어자](https://user-images.githubusercontent.com/55946791/81496271-7cfdc180-92f1-11ea-8c19-2e2f66c70b99.png) 548 | 549 | |접근제어자|설명| 550 | |--|--| 551 | |public| 프로젝트 안에서 자유롭게 사용가능하다 (제한이 전혀없다)| 552 | |protected| 같은 패키지 내에서 and 다른 패지키의 자손 클래스에서 접근 가능| 553 | |default| 같은 패키지 내에서만 접근 가능| 554 | |private| 같은 클래스 내에서만 접근 가능| 555 | 556 | ![접근제어자2](https://user-images.githubusercontent.com/55946791/81496334-de259500-92f1-11ea-9803-6f65defddaf0.png) 557 | 558 | **Q. 접근 제어자의 조합 퀴즈** 559 | 1. 메소드에 static 과 abstract 를 함께 사용 할 수 없다. why ? static 메소드에는 몸통이 있는 메소드에서만 사용 할 수 있기 때문 560 | 2. 클래스에 abstract 와 final 을 동시에 사용 할 수 없다. why ? 클래스에 사용되는 final은 클래스를 확장 할 수 없다는 의미이고, abstract 는 상속 을 통해서 완성되어야 한다는 의미이므로 서로 모순되기 때문이다. 561 | 3. abstract 메소드의 접근 제어자가 private 일 수는 없다. why ? abstract 메소드는 자손클래스에서 구현하기 위해 접근해야 하기 때문이다. 562 | 4. 메소드에 private 과 final 을 같이 사용 할 필요는 없다. why ? 접근제어자가 private 인 메소드는 오버라이딩 될 수 없기 때문이다. 이 둘중 하나만 사용해도 의미가 충분하다. 563 | 564 | 565 | > [참고](https://csw7432.tistory.com/entry/Java-%EC%A0%91%EA%B7%BC%EC%A0%9C%EC%96%B4%EC%9E%90-Access-Modifier) 566 | 567 | 568 | ## 멤버 변수 & 지역 변수 569 | 570 | **멤버 변수** 571 | - 클래스 블록 영역에 선언되는 변수 572 | 573 | **멤버 변수 - static O** 574 | - 클래스 변수, 공통변수, 정적변수, 전역변수 575 | - 컴파일시에 메모리할당, 프로그램 종료시 메모리 해제 576 | - 클래스 전체에서 사용 가능 577 | - 클래스의 모든 인스턴스가 같은 저장공간을 가리킨다 578 | - 저장공간 : Method 영역 579 | 580 | **멤버 변수 - static X** 581 | - 인스턴스 변수 582 | - 객체 생성시마다 따로 저장되는 변수 583 | - 저장공간 : Heap 영역 584 | - GC가 관리한다 585 | 586 | **지역 변수** 587 | - 메소드 블록 영역 588 | - 저장공간 : Stack 영역 589 | 590 | 591 | 592 | >[참고](https://m.blog.naver.com/PostView.nhn?blogId=turtle0720&logNo=60209489019&proxyReferer=https:%2F%2Fwww.google.com%2F) 593 | 594 | 595 | ## non-static 멤버와 static멤버의 차이 설명해주세요 596 | - static은 메서드 or 변수에 붙을수있다. 597 | 598 | - static 사용의 이점 599 | 600 | **static 멤버** 601 | - 공간적 특성 : __멤버는 클래스당 하나 생성__ 602 | - 객체 내부에 생성되는것 이아니고 컴파일시 method영역에 고정적으로 메모리 할당 603 | - 클래스 멤버 604 | - 시간적 특성: __클래스 로딩 시에 멤버 생성__ 605 | - 컴파일시 생성, 프로그램 종료시 메모리 해제 606 | - 객체 생성 하지 않고도 사용가능 607 | - 객체가 사라져도 멤버는 사라지지않음 608 | - 공유의 특성 : __동일한 클래스의 모든 객체들에 의해 공유된다__ 609 | 610 | **non-static 멤버** 611 | - 공간적 특성 : __멤버는 객체마다 별도로 존재__ 612 | - __인스턴스 멤버__ 라고 부른다 613 | - heap 영역 (클래스 내부에서 선언시) or statck 영역(메소드 내에서 생성시) 에 생성 614 | - 시간적 특성 : __객체 생성시 멤버 생성__ 615 | - 객체 생서 후에 사용 가능 616 | - 객체가 사라지면 메모리에서 해제 617 | - 공유의 특성 : __공유x__ 618 | - 멤버는 객체 내에서 각각의 공간을 유지 619 | 620 | > [참고](https://gmlwjd9405.github.io/2018/08/04/java-static.html) 621 | 622 | ## final 키워드 (final/finally/finalize) 설명해주세요 623 | 624 | **final 키워드** 625 | - 변수나 메서드 또는 클래스가 __‘변경 불가능’__ 하도록 만든다. 626 | 627 | - 원시(Primitive) 변수에 적용 시 628 | - 해당 변수의 값 변경X 629 | - final int number = 1; 630 | - 참조(Reference) 변수에 적용 시 631 | - 참조 변수가 힙(heap) 내의 다른 객체를 가리키도록 변경X 632 | - 메서드에 적용 시 633 | - 해당 메서드를 오버라이딩 X 634 | - 클래스에 적용 시 635 | - 해당 클래스를 __상속받을 수 X__ 636 | 637 | **finally 키워드** 638 | - try/catch 블록이 종료될 때 항상 실행될 코드 블록을 정의하기 위해 사용 639 | - finally는 선택적으로 try 혹은 catch 블록 뒤에 정의할 때 사용 640 | - finally 블록은 예외가 발생하더라도 항상 실행 641 | - 단, JVM이 try 블록 실행 중에 종료되는 경우는 제외 642 | - finally 블록은 종종 뒷마무리 코드를 작성하는 데 사용 643 | finally 블록은 try와 catch 블록 다음과, 통제권이 이전으로 다시 돌아가기 전 사이에 실행된다. 644 | 645 | **finalize() 메서드** 646 | 647 | __쓰레기 수집기(GC, Garbage Collector)가__ 더 이상의 참조가 존재하지 않는 __객체를 메모리에서 삭제하겠다고 결정하는 순간 호출__ 된다. 648 | 649 | 쓰레기 수집기(GC, Garbage Collector)가 더 이상의 참조가 존재하지 않는 객체를 메모리에서 삭제하겠다고 결정하는 순간 호출된다. 650 | 651 | 652 | Object 클래스의 finalize() 메서드를 오버라이드해서 맞춤별 GC를 정의할 수 있다. 653 | ```java 654 | protected void finalize() throws Throwable { 655 | /* 파일 닫기, 자원 반환 등등 */ 656 | } 657 | ``` 658 | 659 | 660 | - 개발자가 마음대로 오버라이딩 하면 안좋다. 661 | 662 |
663 | - Q) final과 abstract는 동시에 사용가능하나요 ? -> 아니요. 불가능합니다. 664 | 665 |
666 | - Q) final 과 abstract는 동시에 사용가능하나요 ? -> 아니요.불가능합니다. 667 | 668 | 669 | >[참고](https://gmlwjd9405.github.io/2018/08/06/java-final.html) 670 | 671 | ## 인터페이스와 추상 클래스의 차이(Interface vs Abstract Class) 설명해주세요 672 | 673 | **추상 메서드** 674 | - abstract 키워드 함께 원형만 선언되고, 코드는 작성되지 않는 메서드 675 | 676 | ```java 677 | public abstract String getName(); // 추상메서드 678 | public abstract int getAge() {return 11; }; // 추상 메서드 x 679 | ``` 680 | 681 | **추상 클래스** 682 | - 개념 : abstract 키워드로 선언된 클래스 683 | 1. __추상 메서드를 최소 한 개 이상__ 가지고 abstract로 선언된 클래스 684 | - 최소 한 개의 추상 메서드를 포함하는 경우 __반드시 추상 클래스로 선언__ 685 | 2. 추상 __메서드가 없어도 abstract로__ 선언된 클래스 686 | - 그러나 추상 메서드가 하나도 없는 경우라도 추상 클래스 선언 가능 687 | - 추상 클래스 구현 688 | - 추상 클래스를 __일반 클래스에서 상속__ 받는다면 슈퍼 클래스의 __모든 추상 메서드를 구현해야한다.__ 689 | - 추상 클래스를 추상 클래스에서 상속 시 , 모든 추상 메서드 구현 안해도 된다. 690 | - 추상 클래스 목적 691 | - 객체를 생성하기 위함X, 상속을 위한 부모 클래스로 활용하기 위한 것 692 | - 여러 클래스들의 __공통된 부분을 추상화(추상 메서드)__ 하여 상속받는 클래스에게 구현을 강제화하기 위함 (메서드의 동작을 구현하는 자식 클래스로 책임을 위임) 693 | - 즉, 추상 클래스의 추상 메서드를 자식 클래스가 구체화하여 __기능을 확장 하는데 목적__ 이 있다. 694 | 695 | 696 | **인터페이스** 697 | - 개념 : 추상 메서드와(public abstract) + 상수만을 포함 (public static final), interface 키워드 사용하여 선언 698 | - 인터페이스 구현 699 | - 일반클래스 : 인터페이스를 상속하고, __추상 메서드 모두 구현__ 700 | - 추상클래스: 일부만 구현하면 abstract사용하여 추상클래스로 구현 701 | - 인터페이스 : 인터페이스를 상속받아 새로운 인터페이스 구현 702 | - implements 키워드 사용 하여 구현 703 | - 인터페이스의 목적 704 | - __목적 : 구현 객체의 같은 동작을 보장__ 705 | - 즉, 서로 관련없는 클래스에게 공통적으로 사용하는 방식이 필요핮만 기능을 각각 구현할 필요가 있는 경우 사용 706 | 707 | 708 | |추상 클래스|인터페이스| 709 | |abstract| interface| 710 | |extends| implements| 711 | |목적:상속을 받아서 __기능을 확장__ 시킨다 | 목적:구현 객체의 __같은 동작을 보장__ 하기 위한 목적| 712 | |다중상속 x | 다중 구현 가능| 713 | |클래스o| 클래스 x| 714 | |abstract class Class| interface Interface| 715 | |일반 변수 가질수있다| 일반변수 x , static이 붙은 변수만 있다| 716 | | is a kind of | cand do this| 717 | |Appliances(Abstract Class) - TV, Refrigerator | Flyable(Interface) - Plane, Bird| 718 | 719 | > [참고1](https://gmlwjd9405.github.io/2017/10/01/basic-concepts-of-development-java.html) 720 | > [참고2](https://loustler.io/languages/oop_interface_and_abstract_class/) 721 | 722 | 723 | ## set, list, map의 차이와 각각의 인터페이스 구현체의 종류를 설명해주세요 724 | ![java-collections-framework](https://user-images.githubusercontent.com/55946791/81514002-7ca00d80-9367-11ea-8a58-df497bab5432.png) 725 | 726 | **Map** 727 | - 검색할 수 있는 인터페이스 728 | - 데이터를 삽입할 때 Key와 Value의 형태로 삽입되며, Key를 이용해서 Value를 얻을 수 있다. 729 | - Map: HashMap, LinkedHashMap, HashTable, TreeMap 730 | 731 | **Collection** 732 | - List 733 | - 순서가 있는 Collection 734 | - 데이터를 중복O 735 | - Map: HashMap, LinkedHashMap, HashTable, TreeMap 736 | - Set 737 | - 집합적인 개념의 Collection 738 | - 순서 x 739 | - 데이터를 중복X 740 | - set : HashSet, LinkedHashSet(순서o), TreeSet(이진 검색트리-레드 블랙트리로 구현) 741 | 742 | 743 | >[참고](https://gmlwjd9405.github.io/2017/10/01/basic-concepts-of-development-java.html) 744 | 745 | 746 | ## 오버플로우 747 | - 오버플로우 748 | 데이터마다 크기가 있는데 최대값이 넘어가면 발생, 음수로 넘어간다 749 | - 언더 플로우 750 | 최소값에서 더 작아지면 반대로 최대값으로 넘어간다 751 | 752 | - 아웃오브메모리 753 | - 힙 오버플로우 754 | - 스택 오버플로우 755 | - 스택에서 스택경계를 넘어설때 756 | - 하나 이상의 메소드가 순환 형식으로 상호 호출하면서 스택 내에 함수 호출 수가 끊임없이 증가할 때 발생한다. 757 | 758 | ## Comparable, Comparator 차이 759 | - Comparable : 기본적으로 정렬할때 사용. compareTo()를 오버라이딩 760 | - Comparator : 기본외에 다른 방법으로 정렬할때 사용. compare()오버라이딩 761 | 762 | ## java8을 써보셨나요? java7에서 8로 올라오면서 어떤게 달라졌나요? 763 | - 네 사용해봤습니다. spring프로젝트 때 사용했습니다. 764 | 765 | 766 | **JAVA 7 부터 지원되는것들** 767 | 1. Diamond Operator 768 | - 제네릭스에서 타입 추론가능 769 | 770 | ```java 771 | // Before Java 7 772 | ArrayList arr = new ArrayList(); 773 | 774 | // In Java 7 775 | ArrayList arr = new ArrayList<>(); 776 | ``` 777 | 778 | 2. swith문에 string자료형 사용 가능 779 | 3. 사용한 리소스를 .close()를 이용해서 수동으로 관리하던것을, try문에 선언하면 자동으로 관리가능 780 | 781 | ```java 782 | // before java 7 783 | 784 | try{ 785 | fos = new FileOutputStream("movies.txt"); 786 | } catch(IOException e){ 787 | e.printStackTrace(); 788 | }finally{ 789 | try{ 790 | fos.colse(); 791 | } catch(IOException e){ 792 | } 793 | } 794 | 795 | // java 7 796 | 797 | try{ 798 | fos = new FileOutputStream("movies.txt"); 799 | } catch(IOException e){ 800 | e.printStackTrace(); 801 | } 802 | 803 | ``` 804 | 805 | **JAVA 8 부터 지원되는것들** 806 | > 곧 지원 서비스 만료된다. 11을 사용하는것을 권장한다 807 | 오라클 자바 SE8 무료 지원 종료…"보안 우려 808 | 809 | 1. Lambda Expressions 810 | 811 | ```java 812 | Arrays.asList("a", "b", "c").forEach( e->{ 813 | System.out.println(e); 814 | }); 815 | ``` 816 | 817 | 2. Stream API 818 | - 배열이나 컬렉션 사용시 반복문이나 iterator를 사용했었다 819 | - 이렇게 되면 코드가 길어져서 가독성 저하, 이를 해결 820 | 821 | ```java 822 | String[] arr = new String[]{"넷", "둘", "셋", "하나"}; 823 | 824 | 825 | // 배열에서 스트림 생성 826 | Stream stream1 = Arrays.stream(arr); 827 | stream1.forEach(e -> System.out.print(e + " ")); 828 | ``` 829 | 830 | 3. interface에 default method 생성 가능 831 | 832 | 4. new Date and Time API 833 | - 이전에는 1월~12월을 0~11로 표현하는등 불편함이 있었다 834 | 835 | > :arrow_double_up:[Top](#7-Java) 836 | :leftwards_arrow_with_hook:[Back](https://github.com/devham76/tech-interview-studyw#7-Java) 837 | :information_source:[Home](https://github.com/devham76/tech-intervie-studyw#tech-interview) 838 | 839 | 5. Permanent Heap 영역이(메모리 크기 고정) 제거되었다 840 | - 대신 Native memory 영역에 Meataspace영역이 추가(OS가 자동 조정) 841 | - 따라서 OutOfMemoryError를 보기 힘들다 842 | 843 | **JAVA11** 844 | - 새로운 gc 845 | [java11](https://futurecreator.github.io/2018/09/29/java-11-released/) 846 | 847 | ## this 키워드 848 | 849 | - this는 자기 자신을 의미하는 키워드 850 | - this.은 class내의 변수와 메소드의 매개변수가 동일할 때, class내의 멤버임을 명확하게 해준다 851 | - this()는 자신의 생성자를 호출할때 사용, 호출하는 곳의 첫번째 문장에 작성해야한다 852 | 853 | ```java 854 | public class InstanceMemberEx03 { 855 | String year; 856 | String month; 857 | String day; 858 | 859 | public InstanceMemberEx03(String year) { 860 | this(year, null, null); 861 | } 862 | 863 | public InstanceMemberEx03(String year, String month) { 864 | this(year, month, null); 865 | } 866 | 867 | public InstanceMemberEx03(String year, String month, String day) { 868 | this.year = year; 869 | this.month = month; 870 | this.day = day; 871 | } 872 | } 873 | ``` 874 | 875 | 876 | > :arrow_double_up:[Top](#7-Java) 877 | :leftwards_arrow_with_hook:[Back](https://github.com/devham76/tech-interview-studyw#7-Java) 878 | :information_source:[Home](https://github.com/devham76/tech-intervie-studyw#tech-interview) 879 | 880 | ## 자바에서 tcp udp 소켓 생성 방법 881 | 882 | 883 | 884 | > :arrow_double_up:[Top](#7-Java) 885 | :leftwards_arrow_with_hook:[Back](https://github.com/devham76/tech-interview-studyw#7-Java) 886 | :information_source:[Home](https://github.com/devham76/tech-intervie-studyw#tech-interview) 887 | 888 | ## 리틀엔디안 빅엔디안(★) 889 | 890 | - Little Endian 891 | - 메모리의 첫 주소에 하위 데이터(데이터의 맨 오른쪽)부터 저장 892 | - 연산이 적다 893 | - 인텔이 리틀엔디안을 사용한다 894 | - Big Endian 895 | - 메모리의 첫 주소에 상위 데이터(데이터의 맨 왼쪽)부터 저장 896 | - 사람이 읽는 방법 897 | - 디버그는 빅엔디안이 편하다 898 | - 서버쪽에서 많이 사용하는것 IBM 899 | 900 | - IBM, 인텔 함께 사용할때 오류가 발생할수있다 901 | 902 | - endian : 메모리에 연속된 대상을 배열하는 방법 903 | 904 | >[참고](https://duzi077.tistory.com/201) 905 | > :arrow_double_up:[Top](#7-Java) 906 | :leftwards_arrow_with_hook:[Back](https://github.com/devham76/tech-interview-studyw#7-Java) 907 | :information_source:[Home](https://github.com/devham76/tech-intervie-studyw#tech-interview) 908 | 909 | 910 | ## Reflection 911 | 912 | - Reflection : 반사, 투영하다 913 | - 정의 : 객체를 통해 클래스의 정보를 분석해 내는 프로그램 기법 914 | 915 | - 리플렉션은 __compiler를 무시한 채__ runtime 상황에서 __memory에 올라간 class,method등의 정의를 동적으로 찾아 조적할 수 있는 행위__ 916 | - 즉, 동적인 언어가 가진 특징 917 | - 프레임워크에서 유연성있는 동작을 위해 자주 사용된다 918 |
919 | - 자바 API, getClass ; 코드 작성시점에서 클래스나 메소드가 뭔지 모를때 사용한다. 920 | 921 | > :arrow_double_up:[Top](#7-Java) 922 | :leftwards_arrow_with_hook:[Back](https://github.com/devham76/tech-interview-studyw#7-Java) 923 | :information_source:[Home](https://github.com/devham76/tech-intervie-studyw#tech-interview) 924 | 925 | ## oop 5대 원칙 926 | 927 | - SOILD 원칙 928 | - SRP(단일 책임 원칙) - 응집도는 높게, 결합도는 낮은 프로그램 929 | - OCP(개방-폐쇄 원칙) 930 | - LSP(리스코프 치환 원칙) 931 | - DIP(의존 역전 원칙) 932 | - ISP(인터페이스 분리 원칙) 933 | - 유지 보수와 확장을 위한 원칙 934 | 935 | 1. SRP(단일 책임 원칙) - 응집도는 높게, 결합도는 낮은 프로그램 936 | 937 | 2. OCP(개방-폐쇄 원칙, Open-Closed) 938 | - 기존의 코드를 변경하지 않고(closed) 기능을 수정하거나 추가할수있도록(open) 설계 939 | - 설계할때 변경되는 것이 무엇인지에 초점을 맞춘다. 940 | - 이를 위해 interface가 자주 사용된다 941 | 942 | 3. LSP(리스코프 치환 원칙) 943 | - 자식 클래스는 부모클래스에서 가능한 행위를 수행할수있어야한다. 944 | - 틀린 ex) 945 | - class 도형 { 둘레(){}; 각(){};} 946 | - class 사각형 extends 도형 { 둘레(); 각(){}; } (o) 947 | - class 원 extends 도형 { 둘레(); 각(){}; } (x) 948 | 949 | 4. DIP(의존 역전 원칙) 950 | - 의존 관계를 맺을때, 변하기 쉬운것보다 __변하기 어려운것에 의존해야__ 한다. 951 | 952 | 5. ISP(인터페이스 분리 원칙) 953 | - 클래스에서 자신이 사용하지 않는 인터페이스는 구현하지 않아야 한다 954 | - 따라서 하나의 인스턴스보다는 여러개의 구체적인 인터페이스를 설계하는 것이 좋다 955 | 956 | 957 | > [참고](https://dev-momo.tistory.com/entry/SOLID-%EC%9B%90%EC%B9%99) 958 | 959 | > :arrow_double_up:[Top](#7-Java) 960 | :leftwards_arrow_with_hook:[Back](https://github.com/devham76/tech-interview-studyw#7-Java) 961 | :information_source:[Home](https://github.com/devham76/tech-intervie-studyw#tech-interview) 962 | 963 | ## 직렬화란? 964 | - 자바에서 입출력할때는 __스트림이라는 데이터 통로를__ 통해 이동한다 965 | - 하지만 객체는, 그렇지 않아서 스트림을 통해 저장 or N/W로 전송하는것 불가 966 | - 따라서 __객체를 스트림으로 입출력하기 위해 바이트 배열로 변환하는 것__ 967 | - 역직렬화 : 스트림->객체 968 | -------------------------------------------------------------------------------- /contents/network.md: -------------------------------------------------------------------------------- 1 | # 2. Network 2 | **:book: Contents** 3 | * [tcp/udp의 차이점을 설명하라](#tcp/udp의-차이점을-설명하라) 4 | * [흐름제어기법중 슬라이딩 윈도우 방식에대해 설명하라](#흐름제어기법중-슬라이딩-윈도우-방식에대해-설명하라) 5 | * [브라우저에 네이버홈페이지 url을 입력했을때 일어나는 과정을 설명해라](#브라우저에-네이버홈페이지-url을-입력했을때-일어나는-과정을-설명해라) 6 | * [OSI 7계층에대해 설명하여라](#OSI-7계층에대해-설명하여라) 7 | * [Restful API란?](#Restful-API란?) 8 | 9 | * [3-way handshaking이란?](#3-way-handshaking이란?) 10 | * [HTTP와 HTTPS의 차이는?](#HTTP와-HTTPS의-차이는?) 11 | * [GET과 POST의 차이는?](#GET과-POST의-차이는?) 12 | * [TCP/IP 프로토콜 스택 4계층으로 구분짓고 설명하라](#TCP/IP-프로토콜-스택-4계층으로-구분짓고-설명하라) 13 | * [Session과 Cookie 차이는?](#Session과-Cookie-차이는?) 14 | 15 | --- 16 | * [iocp](#iocp) 17 | * [http keep alive / tcp keep alive](#http-keep-alive-/-tcp-keep-alive) 18 | * [ssl](#ssl) 19 | * [tcp udp 패킷구조 차이점](#tcp-udp-패킷구조-차이점) 20 | * [리피터, 허브, 브릿지, 라우터와 L2, L3, L4, L7 스위치 차이점](#리피터,-허브,-브릿지,-라우터와-L2,-L3,-L4,-L7-스위치-차이점) 21 | 22 | --- 23 | 24 | ## tcp/udp의 차이점을 설명하라 25 | ![tcp udp](https://user-images.githubusercontent.com/55946791/81063602-1ce2d600-8f13-11ea-99e5-f089ca7ccc0c.jpg) 26 | **공통점** 27 | - 데이터 전달을 담당하는 전송계층의 프로토콜이다 28 | 29 | **TCP** 30 | - __연속성보다 신뢰성 있는 전송이 중요할때 사용__ 31 | - 발신지와 수신지를 연결하여 패킷을 전송하기 위한 논리적 경로를 배정하는 가상회선 방식 제공한다. 32 | - 3-way handshaking을 통해 연결하고 4-way handshaking을 통해 해제한다. 33 | - 흐름제어 및 혼잡 제어 34 | - 높은 신뢰성 보장 35 | - 전이중, 점재점 방식 36 | 37 | **UDP** 38 | - __신뢰성보다 연속성이 중요한 서비스에 사용(ex. streaming)__ 39 | - 비연결형 서비스로 데이터그램 방식을 제공 40 | - 정보를 주고 받을대 신호절차 없음 41 | - UDP헤더의 CheckSum필드를 통해 최소한의 오류만 검출 42 | - 신뢰성 낮다 43 | 44 | 45 | | | TCP| UDP| 46 | |--|--|--| 47 | |연결방식 | 연결형 서비스| 비연결형 서비스| 48 | |패킷 교환 방식| 가상 회선 방식| 데이터그램 방식| 49 | |전송 순서| 전송 순서 보장| 전송 순서가 바뀔수있다|| 50 | |수신 여부 확인| 수신여부 확인 | 수신 여부 확인x| 51 | |통신 방식 | 1:1통신 | 1:1 or 1:N or N:N 통신| 52 | |신뢰성| 높다| 낮다| 53 | |속도| 느리다| 빠르다| 54 | 55 | > 56 | 57 | > :arrow_double_up:[Top](#2-network) :leftwards_arrow_with_hook:[Back](https://github.com/devham76/tech-interview-studyw#2-network) :information_source:[Home](https://github.com/devham76/tech-intervie-studyw#tech-interview) 58 | 59 | ## 흐름제어기법중 슬라이딩 윈도우 방식에대해 설명하라 60 | - TCP는 신뢰성을 유지하기 위해 흐름제어, 혼잡제어, 오류제어를 한다. 61 | 62 | **흐름 제어** 63 | - 수신측과 송신측의 데이터 처리 속도 차이를 해결하기 위한 기법 64 | - 송신측 전송량 > 수신측 처리량 일때, __송신측 패킷 전송량을 제어한다.__ 65 | - 정지-대기, 슬라이딩 윈도우가 있다. 66 | 67 | **정지-대기** 68 | ![stop_and_wait](https://user-images.githubusercontent.com/55946791/81066245-c6c46180-8f17-11ea-9f6a-1b4af02ea729.png) 69 | - 매번 전송한 패킷에 대해 응답을 받아야만 다음 패킷을 전송할수있다. 70 | - 간단한 구조, 비효율적 71 | 72 | **슬라이딩 윈도우** 73 | - 전송측이 전송한 프레임에 대한 ACK프레임을 수신하지 않아도, 여러 개의 프레임을 연속적으로 전송하도록 허용하는 방법이다. 74 | - __슬라이딩 윈도우 기법을 통해서 송신 버퍼의 범위는 수신측의 여유 버퍼 공간을 반영하여 동적으로 바뀜으로써 흐름제어를 수행한다__ 75 |
76 | - 윈도우는 전송, 수신 스테이션 양쪽에서 만들어진 버퍼의 크기이다. 77 | - 윈도우의 크기 = (가장 최근 ACK로 응답한 프레임의 수) - (이전에 ACK 프레임을 보낸 프레임의 수) 78 | - ACK 프렝임을 수신하지 않아도 여러 개의 프레임을 연속적으로 전송할 수 있다. 79 | 80 | **슬라이딩 윈도우 과정** 81 | ![error_flow_control_2](https://user-images.githubusercontent.com/55946791/81066242-c62bcb00-8f17-11ea-85fd-b99be68a627b.png) 82 | - 데이커 0,1 전송했다고 가정하면 아래 처럼 변경된다 83 | - 윈도우의 크기는 전송한 데이터 프레임 만큼 왼쪽 경계가 줄어든다. 84 | 85 | ![error_flow_control_3](https://user-images.githubusercontent.com/55946791/81066249-c75cf800-8f17-11ea-814c-d0410e827c25.png) 86 | - 이때 수신측에서 ACK 프레임을 전송하고 수신하면 되면 전송측은 0과 1데이터를 정상적으로 받았음을 알게되고 87 | - 전송측은 ACK 프레임에 따른 프레임의 수만큼 오른쪽으로 경계가 확장된다. 88 | 89 | ![error_flow_control_4](https://user-images.githubusercontent.com/55946791/81066742-8addcc00-8f18-11ea-8a54-af8e34be5255.png) 90 | 91 | > - 92 | > - 93 | 94 | > :arrow_double_up:[Top](#2-network) :leftwards_arrow_with_hook:[Back](https://github.com/devham76/tech-interview-studyw#2-network) :information_source:[Home](https://github.com/devham76/tech-intervie-studyw#tech-interview) 95 | 96 | ## 브라우저에 네이버홈페이지 url을 입력했을때 일어나는 과정을 설명해라 97 | > :arrow_double_up:[Top](#2-network) :leftwards_arrow_with_hook:[Back](https://github.com/devham76/tech-interview-studyw#2-network) :information_source:[Home](https://github.com/devham76/tech-intervie-studyw#tech-interview) 98 | 99 | ## OSI 7계층에대해 설명하여라 100 | ![osi](https://user-images.githubusercontent.com/55946791/81579041-99c7f100-93e6-11ea-961f-0ba2d2962ad6.gif) 101 | 102 | - OSI 7 Layer 란 통신 접속에서 완료까지의 과정을 7단계로 정의한 국제 통신 표준 규약으로 다음과 같이 분류된다. 103 | - 물리계층 : 전송하는데 필요한 기능을 제공. 장비로는 통신 케이블, 허브가 존재한다. 104 | - 데이터링크계층 : 송/수신을 확인. MAC Address를 가지고 통신. 장비로는 브릿지와 스위치가 존재한다. 105 | - 네트워크계층 : 패킷을 네트워크 간의 IP를 통하여 데이터를 전달, 장비로는 라우팅이 존재한다. 106 | - 전송계층 : 두 호스트 시스템으로부터 발생하는 데이터의 흐름을 제공한다. 107 | - 세션계층 : 통신 시스템 사용자간의 연결을 유지 및 설정한다. 108 | - 표현계층 : 세션 계층 간의 주고받는 인터페이스를 일관성 있게 제공한다. 109 | - 응용계층 : 사용자가 네트워크에 접근할 수 있도록 서비스를 제공한다. 110 | > :arrow_double_up:[Top](#2-network) :leftwards_arrow_with_hook:[Back](https://github.com/devham76/tech-interview-studyw#2-network) :information_source:[Home](https://github.com/devham76/tech-intervie-studyw#tech-interview) 111 | 112 | ## Restful API란? 113 | **REST의 구체적 개념** 114 | - __HTTP URI를 통해 자원을 명시하고, HTTP METHOD를 통해 자원에 대한 CRUD를 적용하는 것을 의미한다.__ 115 | - 자원(URI) + 행위(HTTP Method) + 표현 116 | - _자원_ : client는 URI를 이용해서 자원을 지정하고 해당 자원에 대한 조작을 server에 요청하낟 117 | - _행위_ : GET, POST, PUT, DELETE 118 | - _표현_ : JSON, XML를 통해 데이터를 주고 받는 것이 일반적이다. 119 | 120 | 121 | **API(Application Programming Interface)** 122 | - 데이터와 기능의 집합을 제공하여 컴퓨터 프로그램간 상호작용하고 서로 데이터 교환을 가능하게 하는것 123 | 124 | **REST API** 125 | - REST 기반으로 서비스 API를 구현하는것 126 | 127 | **RESTful** 128 | - REST원리를 따르는 시스템을 RESTful 이라고 지칭한다. 129 | 130 | > [참고](https://gmlwjd9405.github.io/2018/09/21/rest-and-restful.html) 131 | 132 | 133 | > :arrow_double_up:[Top](#2-network) :leftwards_arrow_with_hook:[Back](https://github.com/devham76/tech-interview-studyw#2-network) :information_source:[Home](https://github.com/devham76/tech-intervie-studyw#tech-interview) 134 | 135 | ## 3-way handshaking이란? 136 | ![3-way handshaking2](https://user-images.githubusercontent.com/55946791/81298003-1db06f00-90af-11ea-8721-e3f2c14f6255.png) 137 | - client와 server 사이에 논리적인 접속을 성립하기 위해 사용한다. 138 | - TCP/IP프로토콜을 이용해서 통신하는 응용프로그램이 데이터를 전송하기 전에 먼저 정확한 전송을 보장하기 위해 상대방 컴퓨터와 사전에 세션을 수립하는 과정 139 | - client와 server 모두 데이터를 전송할 준비가 되었다는 것을 보장하는것 140 |
141 | - Client > Server : TCP SYN 142 | - Client -> SYN_SNET상태 143 | - Client < Server : TCP SYN ACK 144 | - Server -> SYN_RECEIVED 145 | - Client > Server : TCP ACK 146 | - Server -> ESTABBLISHED 147 | 148 | > :arrow_double_up:[Top](#2-network) :leftwards_arrow_with_hook:[Back](https://github.com/devham76/tech-interview-studyw#2-network) :information_source:[Home](https://github.com/devham76/tech-intervie-studyw#tech-interview) 149 | 150 | ## HTTP와 HTTPS의 차이는? 151 | 152 | ![https](https://user-images.githubusercontent.com/55946791/81301250-c365dd00-90b3-11ea-90e5-95749b593209.png) 153 | 154 | **HTTP** 155 | HTTP는 인터넷에서 웹 서버와 사용자 측의 웹 브라우저 사이에 문서를 전송하기 위한 프로토콜이다 156 | 인터넷에서 HyperText를 전송하기 위해 사용하는 프로토콜이다 157 | 158 | **HTTP의 문제점** 159 | HTTP는 정보를 단순 텍스트로 주고 받기 때문에 (암호화X) N/W상에서 전송 신호를 인터셉트하는 경우 데이터 유출이 발생할수있다. 160 | 161 | **HTTPS** 162 | - SSL이나 TLS 프로토콜을 사용하여 데이터를 암호화한다 163 | - HTTPS는 초기에 C,S가 통신을 하며 암호화 키를 서로 안전하게 주고 받는다.(SSL Handshake) 164 | - 이때 암호화 키값이 노출되지 않도록 안전하게 해주는게 https 서버 인증서이다. 165 |
166 | - SSL(보안 소켓 계층)을 사용함으로써 서버와 브라우저 사이에 안전하게 암호화된 연결을 만든다 167 | - TLS(전송 계층 보안) 프로토콜을 통해서도 보안을 유지한다. 168 | - TLS는 데이터 무결성을 제공하기 때문에 데이터가 전송 중에 수정,손상되는것을 방지한다 169 | 170 | **SSL** 171 | ![https2](https://user-images.githubusercontent.com/55946791/81301245-c234b000-90b3-11ea-910d-9d6112941dba.png) 172 | 173 | > [참고](https://wayhome25.github.io/cs/2018/03/11/ssl-https/) 174 | 175 | > :arrow_double_up:[Top](#2-network) :leftwards_arrow_with_hook:[Back](https://github.com/devham76/tech-interview-studyw#2-network) :information_source:[Home](https://github.com/devham76/tech-intervie-studyw#tech-interview) 176 | 177 | ## GET과 POST의 차이는? 178 | 179 | **GET** 180 | - 주로 조회 할때 사용된다 181 | - 요청데이터를 URL에 파라메터로 담아서 전송한다 182 | - URL에 데이터를 포함해서 전달하므로 전송하는 길이에 제한이있다 183 | - 정적 컨텐츠를 요청하면, 브라우저가 요청을 캐싱해두고 동일 요청이 들어오면 캐싱된 데이터를 전송 184 | 185 | **POST** 186 | - 서버의 상태나 데이터를 생성할때 상용된다 187 | - 요청 정보를 BODY에 담는다 188 | - 요청 BODY는 길이 제한이 없기 때문에 GET과 달리 대용량 데이터 전송 가능 189 | - 요청 헤더의 Content-Type에 요청 데이터의 타입을 표시해야한다 190 | 191 | > :arrow_double_up:[Top](#2-network) :leftwards_arrow_with_hook:[Back](https://github.com/devham76/tech-interview-studyw#2-network) :information_source:[Home](https://github.com/devham76/tech-intervie-studyw#tech-interview) 192 | 193 | ## TCP/IP 프로토콜 스택 4계층으로 구분짓고 설명하라 194 | - LINK 계층(네트워크 인터페이스 계층) 195 | - 물리적인 영역의 표준화에 대한 결과. LAN,WAN,MAN과 같은 NW표준과 관련된 프로토콜을 정의하는 영역 196 | - 물리적 네트워크를 통한 실제 송수신 담당 197 | - 데이터 링크 계층과 물리 계층 198 | 199 | - IP(인터넷 계층) 200 | - 경로검색을 해주는 계층 201 | - IP자체는 비연결지향적이며 신뢰할 수 없는 프로토콜 202 | - 데이터를 전송할 때마다 거쳐야 할 경로를 선택해주지만 그 경로는 일정하지 않다 203 | - 특히 데이터 전송 도중에 경로상의 문제가 발생하면 다른 경로를 선택해주는데, 이 과정에서 데이터가 손실되거나 오류가 발생하는 등의 문제가 발생할수있고 , 이를 해결해주진않는다. 204 | - 즉, 오류발생에 대한 대비가 되어있지 않은 프로토콜이다. 205 |
206 | - 논리 주소인 IP주소를 사용하여 데이터를 목적지 호스트 까지 전달 207 | - 전세계적으로 유일성 보장 208 | 209 | - TCP/UDP(전송) 계층 210 | - 데이터의 실제 송수신을 담당한다 211 | - UDP는 TCP에 비해 상대적으로 간단하다 212 | - TCP는 신뢰성 있는 데이터의 전송을 담당한다 213 | - TCP가 데이터를 보낼 때 기반이 되는 프로토콜은 IP이다. 214 | - IP 계층은 문제 발생시 해결하지않아서 신뢰성이 없다. 215 | - 이 문제를 해결해주는 것이 TCP이다 216 | - 데이터가 순서대로 전송됬는지 확인하며 대화를 주고 받는다 217 | - 확인절차를 걸쳐서 신뢰성 없는 IP에 신뢰성을 부여하는 프로토콜이라고 생각하면 된다 218 | 219 | - APPLICATION 계층 220 | - 이러한 서버와 클라이언트의 프로그램 성격에 때라 데이터 송수신에 대한 규칙이 정해지는데 이를 가리켜 Application 프로토콜이라고 한다 221 | - 어플리케이션 계층, 표현 계층, 세션 층 222 | 223 | --- 224 | 225 | 226 | > :arrow_double_up:[Top](#2-network) :leftwards_arrow_with_hook:[Back](https://github.com/devham76/tech-interview-studyw#2-network) :information_source:[Home](https://github.com/devham76/tech-intervie-studyw#tech-interview) 227 | 228 | ## Session과 Cookie 차이는? 229 | 230 | **쿠키와 세션 사용하는 이유** 231 | - HTTP는 Connectionless(클라이언트가 요청후 응답 받으면 연결 해제), Stateles(통신이 끝나면 상태를 유지하지 않는 특징) 특성이 있다. 232 | - 따라서 Server, Client가 통신할때마다 Server는 Client가 누구인지 인증을 계속해야한다. 233 | - ex) 쿠키와 세션을 사용하지 않으면 쇼핑몰에서 옷을 구매하려고 최초 로그인을 했음에도, 페이지를 이동할 때 마다 계속 로그인을 해야한다. 234 | 왜냐하면, 서버는 클라이언트가 누군지 기억하지 않기 때문 235 | - 쿠키와 세션을 통해 서버는 클라이언트에 대한 인증을 유지한다 (기억하고 있는다) 236 | 237 | **쿠키** 238 | - Client측(브라우저)에서 관리되는 작은 기록정보 파일 239 | - 사용자 인증에 유효한 시간 명시가능, 브라우저 종료되도 인증 유지 240 | 241 | **쿠키 동작** 242 | 1. 클라이언트가 페이지 요청 243 | 2. 서버에서 쿠키 생성 244 | 3. HTTP헤더에 쿠키 포함 시켜 응답 245 | 4. 브라우저가 종료되어도 쿠키 만료 기간이 있다면 __클라이언트에서 보관__ 246 | 5. 쿠기가 존재하면 요청시, HTTP헤더에 쿠키를 함께 보내서 요청 247 | 6. 서버에서 쿠키를 읽어 이전 상태 정보를 변경 할 필요가 있으면, 쿠키를 업데이트하여 변경된 쿠키를 HTTP헤더에 포함시켜 응답 248 | 249 | -> 브라우저 종료시에도 남을수있다 250 | 251 | **쿠키 사용** 252 | - 방문 사이트에서 로그인 시, "아이디, 비밀번호 저장하겠습니까?" 253 | - 쇼핑몰 장바구니 기능 254 | 255 | **세션** 256 | - 사용자 정보 파일을 브라우저에 저장하는 쿠키와 달리 세션은 __서버 측__ 에서 관리 257 | - 서버에서 Client를 구분하기 위해 __세션 ID__ 를 부여 258 | - 웹 브라우저가 서버에 접속해서 브라우저 종료할때 까지인증상태 유지 259 | - __사용자 정보를 서버에 저장하기 때문에 쿠키보다 보안에 좋다__ 260 | - __사용자가 많아질수록 서버 메모리를 많이 차지하게 된다__ 261 | 262 | -> 브라우저가 종료되면 없어진다 263 | 264 | **세션 동작** 265 | 1. 클라이언트가 세버에 접속 시 세션ID 발급 266 | 2. 클라이언트는 세션ID에 대해 쿠키를 사용해서 저장(쿠키 이름 = JSESSIONID) 267 | 3. 클라이언트가 서버에 다시 접속 시 이 쿠키를 이용해서 세션 ID 값을 서버에 전달 268 | 269 | **세션 사용** 270 | - 로그인과 같이 보안상 중요한 작업을 수행할 때 사용 271 | 272 | **둘의 차이** 273 | - __사용자의 기록 정보가 저장되는 위치__ : 쿠키-브라우저, 세션-서버 274 | - __보안__ : 세션이 서버에서 관리 되므로 더 좋다. 275 | - __요청속도__ : 쿠키가 빠르다. 세션은 서버에서 처리가 필요하기 때문이다. 276 | 277 | > [참고](https://victorydntmd.tistory.com/34) 278 | > :arrow_double_up:[Top](#2-network) :leftwards_arrow_with_hook:[Back](https://github.com/devham76/tech-interview-studyw#2-network) :information_source:[Home](https://github.com/devham76/tech-intervie-studyw#tech-interview) 279 | 280 | 281 | ## iocp 282 | 283 | > :arrow_double_up:[Top](#2-network) 284 | :leftwards_arrow_with_hook:[Back](https://github.com/devham76/tech-interview-studyw#2-network) 285 | :information_source:[Home](https://github.com/devham76/tech-intervie-studyw#tech-interview) 286 | 287 | ## http keep alive / tcp keep alive 288 | 289 | **TCP keepalive** 290 | - 서버간에 ACK 패킷을 보내 세션 테이블이 지워지지 않고 계속 __세션 정보를 유지__ 291 | - mq, kafka 등 TCP 기반의 서비스들을 대상으로 __지속적 연결을 유지해야 하는 경우__ 사용 292 | - 과정 293 | 1. A – B가 서로 Connection이 Establish된 상태에서 (3-handshake) 294 | 2. 지정된 시간(OS 설정 값 또는 어플리케이션 설정) 동안 서로 패킷 교환(Exchange)이 없을경우 295 | 3. payload가 없는 패킷을 보냅니다. 296 | 4. 패킷에 반응없으면 접속 close 297 | 298 | - 언제사용하지? 299 | - 한쪽만 연결되어있는 상태를 정리하기 위해 사용 300 | 301 | ``` 302 | 1. Checking for dead peers 303 | 304 | A – B가 연결된 경우 B시스템이 장애로 인해서 restart 될 경우 305 | A의 keep-alive 설정에 의해서 probe 패킷을 보내면 306 | B는 RST(Reset)을 응답 합니다. 307 | 308 | 이럴 경우 B 시스템의 커넥션이 끊겼다는 것을 감지 할 수 있습니다. 309 | 310 | ※ TCP 프로토콜 자체에서 장애 감지가 없기 때문에 Keepalive 옵션을 311 | 통해서 감지 312 | ``` 313 | 314 | 315 | **HTTP Keepalive** 316 | - http 는 특성상 커넥션을 유지하지 않는다. 317 | - 따라서 KeepAlive를 사용해서 __커넥션을 유지해서 빠르게 데이터 주고받을__ 수 있다. 318 | - 일정시간이 지나면 __능동적으로 연결을 끊는다.__ 319 | - 너무 많은 연결을 오래 유지하면, 다른 연결에 방해를 줄수있다. 320 |
321 | - Apache, Nginx 등 웹 애플리케이션에서 __설정된 기간까지 최대한 연결을 유지하기 위해__ 사용된다. 322 | 323 | - HTTP 1.1부터 keepalive를 default로 제공한다 324 | 325 | 326 | > :arrow_double_up:[Top](#2-network) 327 | :leftwards_arrow_with_hook:[Back](https://github.com/devham76/tech-interview-studyw#2-network) 328 | :information_source:[Home](https://github.com/devham76/tech-intervie-studyw#tech-interview) 329 | 330 | ## ssl 331 | - HTTP의 보안 문제를 해결해준다. SSL이 적용되어 HTTPS라고 칭한다 332 | - http와 tcp사이에 있는 인증서. TLS가 정식명칭이나, SSL이라고 부른다 333 | - 동작 334 | 1. Server측에서 CA(인증기관)에 사이트정보+공개키를 주고 인증서를 요청한다 335 | 2. CA에서 심사완료 후 사이트정보+공개키를 개인키로 암호화 하고 공개키를 브라우저에 등록한다 336 | 3. 브라우저가 서버에 인증서를 요청한다 337 | 4. 인증서가 CA에서 인증받은것인지 브라우저가 확인하고 공개키를 이용해서 서버측 사이트정보+공개키를 획득한다 338 | 5. 클라이언트의 대칭키를 서버측의 공개키로 암호화 해서 서버에게 전송한다 339 | 6. 서버는 자신의 개인키로 복호화하여 클라이언트 측의 대칭키를 획득한다 -> 그러면, 대칭키는 클라이언트,서버만 갖게 된다 340 | 7. 이 대칭키로 암호화,복호화하여 통신한다 341 | > 342 | 343 | > :arrow_double_up:[Top](#2-network) 344 | :leftwards_arrow_with_hook:[Back](https://github.com/devham76/tech-interview-studyw#2-network) 345 | :information_source:[Home](https://github.com/devham76/tech-intervie-studyw#tech-interview) 346 | 347 | ## tcp udp 패킷구조 차이점 348 | ![TCP패킷](https://user-images.githubusercontent.com/55946791/81794325-94cd8380-9545-11ea-938a-ab551f055ace.png) 349 | ![UDP (1)](https://user-images.githubusercontent.com/55946791/81794335-96974700-9545-11ea-8c04-13c1fb79bd37.png) 350 | 351 | 352 | > :arrow_double_up:[Top](#2-network) 353 | :leftwards_arrow_with_hook:[Back](https://github.com/devham76/tech-interview-studyw#2-network) 354 | :information_source:[Home](https://github.com/devham76/tech-intervie-studyw#tech-interview) 355 | 356 | ## 리피터, 허브, 브릿지, 라우터와 L2, L3, L4, L7 스위치 차이점 357 | - 리피터 358 | - 리피터 란? 근거리통신망(LAN)의 전송매체상에 흐르는 신호를 정형, 증폭, 중계하는 장치 359 | - 허브 360 | - 다수의 pc와 장치들을 묶어서 LAN을 구성할때 한곳으로 모으는 역할, 플러딩 발생한다 361 | - 브릿지 362 | - 데이터 링크 계층에 있는 여러 개의 네트워크 세그먼트를 연결해 준다 363 | - 들어오는 데이터 패킷을 분석하여 브리지가 주어진 패킷을 다른 세그먼트의 네트워크로 전송할 수 있는지를 결정할 수 있다. 364 | - 라우터 365 | - 어드레싱과 라우팅을 한다 366 | - 어드레싱 : MAC주소를 알아낸다 367 | - 라우팅 : 다음 목적지의 경로를 알아낸다 368 | - 스위치 369 | - OSI의 7 레이어 중 어떤 레이어에서 수행되는가에 따라 정의된 분류이다. 370 | - 371 | 372 | > :arrow_double_up:[Top](#2-network) 373 | :leftwards_arrow_with_hook:[Back](https://github.com/devham76/tech-interview-studyw#2-network) 374 | :information_source:[Home](https://github.com/devham76/tech-intervie-studyw#tech-interview) 375 | 376 | ## 로드밸런싱이란? 377 | -------------------------------------------------------------------------------- /contents/os.md: -------------------------------------------------------------------------------- 1 | ## 3. Operating System 2 | **:book: Contents** 3 | 4 | - [OS란 무엇이며, 핵심 기능은?](#OS개념과-핵심-기능) 5 | - [부팅이 되는 과정을 설명하시오.](#부팅이-되는-과정) 6 | - [프로세스의 5가지 상태에 대해 설명하시오.](#프로세스의-5가지-상태) 7 | - [메모리 계층 구조를 설명하시오.](#메모리-계층-구조) 8 | - [캐시와 버퍼의 차이점은?](#캐시와-버퍼의-차이점) 9 | 10 | * [세마포어와 뮤텍스란? 차이점은 무엇인가?](#세마포어와 뮤텍스란?-차이점은-무엇인가?) 11 | * [메모리 단편화, 페이징, 세그멘테이션](#메모리-단편화,-페이징,-세그멘테이션) 12 | * [선점스케줄링과 비선점스케줄링, 해당하는 알고리즘 한개씩](#선점스케줄링과-비선점스케줄링,-해당하는-알고리즘-한개씩) 13 | * [문맥교환이란?](#문맥교환이란?) 14 | * [PCB란?](#PCB란?) 15 | 16 | 17 | * [가상메모리란?](#가상메모리란?) 18 | * [Deadlock이란?](#Deadlock이란?) 19 | * [프로세스의 메모리구조?](#프로세스의-메모리구조?) 20 | * [thrashing이란?](#thrashing이란?) 21 | * [프로세스간 통신하는 방법은?](#프로세스간-통신하는-방법은?) 22 | 23 | 24 | * 멀티프로세싱, 멀티프로그래밍, 멀티스레딩, 멀티태스킹 25 | * 톰캣은 멀티 프로세스인가 멀티 스레드인가 26 | * 아파치는 멀티 프로세스인가 멀티 스레드인가 27 | * 동기, 비동기, 블로킹, 넌블로킹 차이 28 | * 스레드와 프로세스의 차이 29 | * Thread 가 3개 생성 되었을 때 t1, t2, t3의 순서가 보장 되는 코드를 짜 보세요. 30 | 31 | --- 32 | 33 | ## OS개념과 핵심 기능 34 | **운영체제란** 35 | H/W와 S/W 사이에서 둘을 효율적으로 운영하고 관리하여 36 | 사용자가 컴퓨터를 편리하게 사용할수 있도록 하는 프로그램 37 | 38 | **운영체제 기능** 39 | 1. 자원관리 40 | - 컴퓨터 시스템을 구성하는 cpu, 기억장치, 주변장치, data등 컴퓨터 자원을 관리한다 41 | 42 | 2. 프로세스 관리 43 | - 프로세스와 쓰레드 스케줄링, 프로세스 생성과 제거, 프로세스 시작, 정지, 재수행 44 | - 프로세스 동기화 및 통신, 주기억 장치 관리를 위해 주기억장치 관리자와 협력 45 | 46 | 3. 기억장치 관리 47 | - 메모리 상태 추적, 메모리 할당 및 회수, 가상기억장치 및 페이징 장치 관리, 장치 관리자 또는 파일 관리자와 협력 48 | 49 | 4. 입출력 장치 관리 50 | - 입출력 장시의 스케줄 관리, 각종 주변장치의 스케줄링 및 관리 51 | 52 | 5. 파일 관리 53 | - 파일 생성과 삭제, 변경 유지들의 관리 54 | - 정보의 위치, 사용여부와 상태 등을 추적 관리 55 | 56 | > 57 | 58 | > :arrow_double_up:[Top](#3-os) :leftwards_arrow_with_hook:[Back](https://github.com/devham76/tech-interview-studyw#3-os) :information_source:[Home](https://github.com/devham76/tech-intervie-studyw#tech-interview) 59 | 60 | ## 부팅이 되는 과정 61 | > 62 | 63 | > :arrow_double_up:[Top](#3-os) :leftwards_arrow_with_hook:[Back](https://github.com/devham76/tech-interview-studyw#3-os) :information_source:[Home](https://github.com/devham76/tech-intervie-studyw#tech-interview) 64 | 65 | ## 프로세스의 5가지 상태 66 | ![프로세스 상태](https://user-images.githubusercontent.com/55946791/80938240-559b8600-8e13-11ea-9176-a121491a0fb3.jpg) 67 | 1. 생성 : 프로세스 생성 상태 , pcb를 할당받은 상태 68 | 2. 실행 : 프로세스가 cpu에 할당되어 실행 중인 상태 69 | 3. 준비 : 프로세스가 cpu에 할당되기를 기다리는 상태 70 | 4. 대기 : 보류(block)라고도 하며, 프로세스가 입출력이나 이벤트릴 기다리는 상태 71 | 5. 종료 : 프로세스 종료 상태 72 | 73 | > 74 | 75 | > :arrow_double_up:[Top](#3-os) :leftwards_arrow_with_hook:[Back](https://github.com/devham76/tech-interview-studyw#3-os) :information_source:[Home](https://github.com/devham76/tech-intervie-studyw#tech-interview) 76 | 77 | ## 메모리 계층 구조 78 | ![메모리 계층](https://user-images.githubusercontent.com/55946791/80938438-128de280-8e14-11ea-8207-95cb98d94303.jpg) 79 | 80 | **메모리 종류** 81 | 1. Main 메모리 : 램 (RAM) 82 | 2. Register : cpu안에 내장되어 있어 연산을 위한 저장소 제공 83 | 3. Cache : cpu와 RAM사이에서 중간 저장소 역할 84 | 4. Hard Disk와 이외 장치 : 하드디스크, I/O장치 등 85 | (* CPU와 거리가 가까울수록, 빠르고 용량이 작다. 멀수록, 느리고 용량이 크다) 86 | 87 | **데이터 이동** 88 | - 프로그램의 실행을 위해 하드디스크에 있는 내용은 메인 메모리로 이동한다 89 | - 메인 메모리에 있는 일부 데이터도 실행을 위해 L2캐시로 이동한다 90 | - L2캐시에 있는 데이터 일부는 L1캐시로 이동한다 91 | - L1캐시에 있는 데이터 중 연산이 필요한 데이터는 레지스터로 이동한다. 92 | 93 | > 94 | 95 | > :arrow_double_up:[Top](#3-os) :leftwards_arrow_with_hook:[Back](https://github.com/devham76/tech-interview-studyw#3-os) :information_source:[Home](https://github.com/devham76/tech-intervie-studyw#tech-interview) 96 | 97 | ## 캐시와 버퍼의 차이점 98 | 99 | **캐시** 100 | - 이전에 접근한 데이터를 빠르게 접근하기 위해 임시로 저장 101 | - 교체 알고리즘에 따라 삭제될수도 안될수도있다 102 | - 캐시는 어떤 원리로 저장되나요? __지역성__ / (시간, 공간) 103 | - 한번 참조되면 가까운 미래에 또 사용될수있다 104 | - 참조된 메모리에 가까운 곳에 있는 데이터가 또 사용될수있다 105 | 106 | **버퍼** 107 | - 전송전에 임시로 저장 108 | - 미리 출력할것을 버퍼에 담아서 성능 빠르게 109 | - 사용후에 바로 삭제 된다 110 | 111 | 112 | > :arrow_double_up:[Top](#3-os) :leftwards_arrow_with_hook:[Back](https://github.com/devham76/tech-interview-studyw#3-os) :information_source:[Home](https://github.com/devham76/tech-intervie-studyw#tech-interview) 113 | 114 | 115 | 116 | ## 세마포어와 뮤텍스란? 차이점은 무엇인가? 117 | 118 | **세마포어와 뮤텍스 정의** 119 | - 여러 프로세스나 쓰레드가 __공유 자원에 접근하는 것을 제어하기__ 위한 방법 120 | - __병행 처리를 위한 프로세스 동기화 기법__ 121 | 122 | **세마포어** 123 | - 세마포어 변수, wait()함수, signal()함수가 있다. 124 | - 세마포어 변수 : 공유 가능한 자원의 수 125 | - wait() : 세마포어 값을 감소 시킨다. 음수가되면 호출한 프로세스는 블록된다. 126 | - signal() : 실행되던 프로세스가 종료되어, 세마포어 값을 증가시킨다. 만약 값이 0이거나 음수면, swmWait연산에 의해 블록된 프로세스를 wake_up한다 127 |
128 | - 세마포어 종류 : binary 세마포어(세마포어가 0또는1만허용), counting 세마포어(0또는1이상의수를 가질수있다) 129 | 130 | **뮤텍스** 131 | - 초기값을 1과0으로 가진다 132 | - 임계구역에 들어갈때 락(lock)을 걸어 다른 프로세스(or 쓰레드)가 접근하지 못하도록하고 133 | - 임계구역에서 나올때 해당 락을 해제(unlock)한다. 134 | 135 | **뮤텍스와 세마포어의 차이** 136 | - 세마포어는 공유 자원에 __세마포어의 변수만큼 프로세스(or 쓰레드)가__ 접근할 수 있다 137 | - 반면에 뮤텍스는 __오직 1개만의 프로세스(or 쓰레드)만 접근 가능 138 |
139 | - 현재 수행중인 프로세스가 아닌 __다른 프로세스가 세마포어 해제__ 가능 140 | - 뮤텍스는 __락(lock)을 획득한 프로세스가 반드시 그 락을 해제__ 해야 한다. 141 | 142 | > [참고](https://velog.io/@conatuseus/OS-%EC%84%B8%EB%A7%88%ED%8F%AC%EC%96%B4%EC%99%80-%EB%AE%A4%ED%85%8D%EC%8A%A4) 143 | 144 | > :arrow_double_up:[Top](#3-os) :leftwards_arrow_with_hook:[Back](https://github.com/devham76/tech-interview-studyw#3-os) :information_source:[Home](https://github.com/devham76/tech-intervie-studyw#tech-interview) 145 | 146 | ## 메모리 단편화, 페이징, 세그멘테이션 147 | 148 | 149 | - 세그멘테이션-가변적으로 자른다 / 장점,단점 150 | - 페이지-고정된 크기로 자른다 / 장점, 단점 151 | - 물리메모리- 프레임 152 | - 가상메모리- 페이지 153 | 154 | **메모리 단편화** 155 | - 메모리의 공간이 작은 조각으로 나뉘어져서 __사용가능한 메모리가 충분히 존재하지만 할당(사용)이 불가능한 상태__ 156 | 157 | **외부 단편화** 158 | - 메모리가 할당되고 해제되는 작업이 반복되면서 작은 메모리가 중간중간에 존재 159 | - 이 때 중간에 생긴 사용하지 않은 메모리가 많이 존재해서 총 메모리 공간은 충분하지만 실제로 할당할수 없는 상황 160 | 161 | **내부 단편화** 162 | - __프로세스가 필요한 양보다 더 큰 메모리가 할당 되어서__ 프로세스에서 사용하는 메모리가 낭비되는 상황 163 | 164 | 165 | **페이징 기법** 166 | - 외부 단편화 해결, 내부 단편화 존재 167 | - __가상메모리를__ 같은 크기의 블록으로 나눈것을 __페이지__ 라고한다. 168 | - __물리메모리를__ 같은 크기의 블록으로 나눈것을 __프레임__ 이라고 한다. 169 |
170 | - 방법 171 | - 프로세스를 페이지 단위로 나눈 뒤에, 사용하지 않는 영역을 보조기억장치에 적재한다. 이를 페이징 되었다고 하는데, 만약 이 페이징 된 영역에 접근해야 하면 페이징 폴트를 발생시킨 후 메모리에 적재시킨다(요구 페이징). 페이징된 정보는 페이징테이블에 저장된다. 172 | 173 | - 장점 174 | - 연속적이지 않은 공간도 활용할수 있기 때문에 외부 단편화 문제를 해결 할 수 있다. 175 | - 단점 176 | - 내부 단편화가 발생할 수 있다 177 | 178 | **페이지 테이블이란 ?** 179 | - 페이징 기법에서 사용되는 자료구조로서, __프로세스의 페이지 정보를 저장하고__ 있는 테이블이다. 180 | 181 | **세그멘테이션 기법** 182 | - 내부 단편화 해결, 외부 단편화 존재 183 | - 가상메모리를 __서로 크기가 다른 논리적 단위인 세크멘트로 분할해서 메모리를 할당__ 하여 실제 메모리 주소로 변환을 하게 된다. 184 | - 각 세그먼트는 __연속적인 공간에 저장__ 되어 있다. 185 | - 세그먼트들의 크기가 다르기 때문에 미리 분할해 둘 수 없고 메모리에 적재될 때 빈공간을 찾아 할당하는 기법. 186 | 187 | > [참고](https://jeong-pro.tistory.com/91) 188 | 189 | > :arrow_double_up:[Top](#3-os) :leftwards_arrow_with_hook:[Back](https://github.com/devham76/tech-interview-studyw#3-os) :information_source:[Home](https://github.com/devham76/tech-intervie-studyw#tech-interview) 190 | 191 | ## 선점스케줄링과 비선점스케줄링, 해당하는 알고리즘 한개씩 192 | 193 | - 선점 알고리즘 : 어떤 프로세스가 CPU를 할당 받아 실행 중이더라도 OS가 CPU를 강제로 빼앗을 수 있다. 194 | 195 | **비선점 알고리즘** 196 | - FCFS 197 | - SJF(Shortest Job First, 실생 시간이 가장 짧은 작업부터) 198 | - HRN(Highest Response Ratio Next, 최고 응답률 우선 스케줄링) 199 | 200 | **선점 알고리즘** 201 | - RR(Round Robin) : 할당받은 시간(타임 슬라이스)동안 작업 하다가 작업 미완료시 준비 큐의 맨뒤로 간다. 202 | - SRT(Shortest Remaining Time) : SJF + RR 방식 203 | - 최소 잔류 시간 우선 스케줄링 204 | - 남은 시간이 적은 프로세스에 CPU를 먼저 할당 205 | - 다단계 큐 스케줄링 206 | - 우선순위에 따라 준비 큐가 여러개 207 | - 상단의 큐에 있는 모든 프로세스가 종료되야 다음 우선순위 큐의 작업이 시작된다. 208 | - 다단계 피드백 큐 스케줄링 209 | - __우선순위가 낮은 프로세스에 불리한 다단계 큐 스케줄링__ 을 보완한 방식 210 | - CPU를 사용하고 난 프로세스는 원래 큐로 돌아가지않고, 우선순위가 하나 낮은 큐의 끝으로 들어간다. 211 | - 우선순위를 낮춤으로써, 다단계 큐에서 우선순위가 낮은 프로세스의 실해이 연기되는 문제를 완화한다. 212 | 213 | **둘 다 가능** 214 | - 우선순위 스케줄링 215 | - 프로세스는 중요도에 따라 우선순위를 갖는다. 216 | - 일정 시간마다 우선순위가 변하거나 고정되거나 217 | 218 | > :arrow_double_up:[Top](#3-os) :leftwards_arrow_with_hook:[Back](https://github.com/devham76/tech-interview-studyw#3-os) :information_source:[Home](https://github.com/devham76/tech-intervie-studyw#tech-interview) 219 | 220 | ## 문맥교환이란? 221 | - CPU를 차지하던 프로세스가 나가고 새로운 프로세스를 받아들이는 작업을 말한다. 222 | - 두 프로세스의 PCB를 교환 하는 작업 223 | - 현재까지의 작업 상태를 저장하고 다음 작업에 필요한 각종 상태, 데이터를 읽어오는 작업 224 |
225 | - 멀티 프로세스 환경에서 CPU 스케줄러가 인터럽트 발생 시 현재 프로세스의 상태를 PCB에 저장하고, 새로운 프로세스의 상태를 레지스터에 저장하는 것을 말함. 226 | - 인터럽트의 종류 : 227 | - I/O Request : 입출력 요청 228 | - Time Slice Expired : CPU 사용시간 만료 229 | - Fork Child : 자식 프로세스 생성 230 | - Wait for interrupt : 인터럽트 처리 대기 231 | 232 | - 컨텍스트 스위칭 시 CPU는 아무런 작업을 하지 못한다. 따라서 잦은 컨텍스트 스위칭은 성능 저하를 일으킴. 233 | 234 | > :arrow_double_up:[Top](#3-os) :leftwards_arrow_with_hook:[Back](https://github.com/devham76/tech-interview-studyw#3-os) :information_source:[Home](https://github.com/devham76/tech-intervie-studyw#tech-interview) 235 | 236 | ## PCB란? 237 | - __프로세스를 실행하는 데 필요한 중요한 정보를 보관하는 자료구조__ 238 | - __각 프로세스가 생성될 때마다 고유의 PCB가__ 생성되고, 완료되면 제거된다. 239 |
240 | - 프로세스는 CPU를 할당받아 작업을 처리하다가, CPU를 선점 당하게 되면 진행 중이던 작업 내용을 PCB에 저장하고 CPU를 반환한다. 241 | - 이후에 다시 CPU를 할당받으면 PCB로 부터 진행이 끊겼던 부분에서 다시 작업을 실행한다 242 | - 프로세스 식별자, 상태, PC(프로그램 카운터, 다음 실행할 명령의 주소 가르킴), 메모리 관리 정보 등을 가지고 있다. 243 | 244 | > :arrow_double_up:[Top](#3-os) :leftwards_arrow_with_hook:[Back](https://github.com/devham76/tech-interview-studyw#3-os) :information_source:[Home](https://github.com/devham76/tech-intervie-studyw#tech-interview) 245 | 246 | ## 가상메모리란? 247 | 실제 시스템에 있는 물리적인 메모리의 크기에 상관 없이 가상 공간을 프로세스에게 제공합니다. 이런 가상 메모리는 프로세스 전체가 메모리에 적재되지 않아도 프로세스의 실행이 가능하도록 합니다. 248 | 249 | 250 | > [참고](https://ko.wikipedia.org/wiki/%EA%B0%80%EC%83%81_%EB%A9%94%EB%AA%A8%EB%A6%AC) 251 | 252 | > [참고](https://twinw.tistory.com/106?category=543743) 253 | 254 | - 가상메모리 어떻게 구현하나요 ? - 페이징, 세크멘테이션 255 | 256 | ## Deadlock이란? 257 | 258 | - 교착 상태란 두 개 이상의 작업이 서로 __상대방의 작업이 끝나기 만을 기다리고__ 있기 때문에 결과적으로 아무것도 완료되지 못하는 상태를 가리킨다 259 | 260 | 261 | ## Deadlock이란? 262 | 263 | - 교착 상태란 두 개 이상의 작업이 서로 상대방의 작업이 끝나기 만을 기다리고 있기 때문에 결과적으로 아무것도 완료되지 못하는 상태를 가리킨다 264 | 265 | - 멀티프로세스나 멀티쓰레드 환경에서 __여러 프로세스들이 한정된 자원을__ 사용하기 때문에 발생할 수 있다 266 | 267 | 268 | **데드락 발생 조건** 269 | - 모두 충족해야 발생 270 | 271 | 1. 상호배제 272 | - 자원은 한 번에 한 프로세스만이 사용할수 있다 273 | 2. 점유대기 (Hold and wait) 274 | - 자원을 할당받은 상태에서 다른 자원을 기다리는 상태 275 | 3. 비선점 276 | - 다른 프로세스에 할당된 자원은 사용이 끝날 때까지 강제로 뺏을수 없다 277 | 4. 순환 대기 (Circular wait) 278 | - 점유와 대기를 하는 프로세스 간의 관계가 원을 이룬다. 279 | - 점유와 대기를 하는 프로세스들이 서로 방해하는 방향이 원을 이루면, 프로세스들이 서로 양보하지 않기 때문에 교착상태 발생 280 | 281 | **데드락 처리 - 1.예방** 282 | - 교착 상태 발생 조건 중 하나를 제거함으로써 해결 283 | 1) 상호배제 부정 : 여러 개의 프로세스가 공유 자원 사용가능 (보호해야할 자원을 공유하기힘들다) 284 | 2) 점유대기 부정 : 자원을 점유한상태에서 다른 자원 기다리지 못함. (전부 할당 or 아예할당x) 285 | 3) 비선점 부정 : 자원을 빼앗을 수 있도록 만든다 (우선순위가 낮은 프로세스 기아현상) 286 | 4) 순환대기 부정 : 모든 자원에 숫자를 부여하고 숫자가 큰 방향으로만 자원할당(번호 부여 방식 선정 어려움) 287 | - 문제점 : 288 | - 자원을 보호하기 위해 1.상호배제, 3.비선점을 예방하기 어렵고 289 | - 2.점유대기, 4.순환대기는 프로세스 작업 방식을 제한하고 자원을 낭비한다 290 | 291 | **데드락 처리 - 2.회피** 292 | - 교착 상태가 발생하면 피하는 방법 293 | - 교착 상태가 발생하지 않는 범위 내에서만 자원할당, 교착 상태 발생하는 범위에서 프로세스 대기 294 | - 교착 상태 예방보다 좀 더 유연하다. 295 | 296 | **은행원 알고리즘 (Banker’s Algorithm)** 297 | - 은행이 대출 해주는 방식. 즉, 대출 금액이 대출 가능한 범위이면(안정 상태) 허용, 그렇지 않으면 거부. 298 | - 안정 상태에 있으면 자원을 할당하고, 그렇지 않으면 다른 프로세스들이 자원을 해지할 때까지 대기함 299 |
300 | - 최대 자원 : 자신이 사용할 자원의 최대수 301 | - 할당 자원 : 할당된 자원수 302 | - 기대 자원 : 최대자원 - 할당 자원 303 | - 가용 자원 : 남은 자원의 수 304 |
305 | - 문제점 : 306 | - 모든 프로세스가 __자신이 사용할 모든 자원을 미리 알기 어렵다__ 307 | - 시스템의 전체 자원 수는 유동적이므로 전체 자원 수를 고정하기 어렵다 308 | - 자원 낭비 ; 실제로 교착상태가 발생하지 않았지만 발생할 것이라고 예상하여, _프로세스에 자원 할당하는 것에 제약_ 을 둔다. 309 | 310 | **데드락 처리 - 3.탐지** 311 | - os가 프로세스의 작업을 관찰하면서 데드락 발생 여부를 계속 주시 312 | 313 | **타임아웃** 314 | - __일정 시간 동안 작업이 진행되지 않은 프로세스를__ 데드락 발생한것으로 간주하여 처리 315 | - 자원 할당 그래프를 이용하는것보다 쉽기 때문에 선호한다 316 | 317 | **자원 할당 그래프** 318 | - 자원할당 그래프를 통해 프로세스가 어떤 자원을 사용, 기다리는지 알 수 있다 319 | - 장점 : 프로세스의 작업 방식을 제한하지 않으면서 교착상태를 정확하게 파악 320 | - 단점 : 자원 할당 그래프를 유지, 갱신, 사이클 검수하면서 __오버헤드가 발생__ 321 | - 추가 작업을 줄이기 위해 자원 할당시마다 사이클 검사X, 일정 시간마다 검사하는 방법도 있음 322 | 323 | 324 | 325 | **데드락 처리 - 4.회복** 326 | - 데드락 발생 시킨 프로세스 종료하거나 할당된 자원을 해제 하여 회복하는 것을 의미 327 | 1. 교착상태 발생시킨 프로세스 동시에 종료 328 | 2. 교착상태 발생시킨 프로세스 중 하나를 골라 순서대로 종료 329 | - 우선순위 낮은 프로세스 종료 330 | - 작업 시간 짧은 프로세스 종료 331 | - 자원을 많이 사용하는 프로세스 종료 332 | 333 | > [참고](https://jwprogramming.tistory.com/12) 334 | > [참고 - 쉽게 배우는 운영체제] 335 | 336 | ## 프로세스의 메모리구조? 337 | 338 | ![메모리 구조](https://user-images.githubusercontent.com/55946791/81517248-423d6d00-9375-11ea-9cfe-84f20b7b4740.jpg) 339 | - 메모리 영역은 크게 두가지로 나눌 수 있는데 컴파일시 크기가 고정되는 code, data, bss 영역과 실행시 메모리가 할당되었다 반납되는 heap, stack영역으로 나눌 수 있다. 340 | 341 | 342 | 1. 메모리 할당이 고정되는 영역 (compile시 결정) 343 | 344 | * code영역 345 | - 실행 파일을 구성하는 명령어들이 올라가는 메모리 영역으로 함수, 제어문, 상수 등이 여기에 지정된다. 346 | 347 | * data 영역 & BSS 348 | - data 영역은 BSS와 함께 묶어서 데이터 영역으로 칭하기도 하는데 이는 전역변수와 static변수가 지정되는 영역이다. 349 | - 초기화 되지 않은 전역변수들은 BSS에 지정된다. 350 | - data :초기값 있는 전역밴수, 배열, static으로 선언된 변수 351 | - bss : 초기값 없는 전역변수, 배열, static으로 선언된 변수 352 | 353 | 2. 실행 중에 메모리를 할당하는 영역(할당과 반납이 이루어짐) 354 | - data 영역은 BSS와 함께 묶어서 데이터 영역으로 칭하기도 하는데 이는 전역변수와 Static변수가 지정되는 영역이다. 355 | - 초기화 되지 않은 전역변수들은 BSS에 지정된다. 356 | 357 | 358 | 2. 실행 중에 메모리를 할당하는 영역(할당과 반납이 이루어짐) 359 | 360 | * HEAP 영역 361 | - malloc(), calloc() 등으로 프로그래머가 자율적으로 메모리 크기를 할당할 수 있는 영역이다. 362 | - 위의 함수들은 free()함수로 할당된 영역을 반납해줘야하므로 동적할당 영역에 속한다. 363 | 364 | * STACK 영역 365 | - 지역변수가 할당되는 영역으로 함수가 호출되면 할당되었다 함수의 종료시 반납되는 영역이다. 366 | 367 | 368 | **메모리 오버플로우** 369 | - 위의 HEAP과 STACK영역은 사실 같은 공간을 공유한다. 370 | - HEAP이 메모리 위쪽 주소부터 할당되면 STACK은 아래쪽 부터 할당되는 식이다. 371 | - 그래서 각 영역이 상대 공간을 침범하는 일이 발생할 수 있는데 이를 각각 HEAP OVERFLOW, STACK OVERFLOW라고 칭한다. 372 | 373 | ![메모리 오버플로우](https://user-images.githubusercontent.com/55946791/81517246-410c4000-9375-11ea-8d4e-fc9bb40d0387.jpg) 374 | 375 | > [참고](https://zapiro.tistory.com/entry/%ED%95%A8%EC%88%98%EC%99%80-%EB%A9%94%EB%AA%A8%EB%A6%AC-%EC%98%81%EC%97%AD) 376 | 377 | ## thrashing이란? 378 | 379 | - 가상메모리 크기 = 물리메모리 + 스왑영역 (하드디스크에 존재 or 멤리 관리자가 관리하는 영역) 380 | 381 | **페이지 부재(페이지 폴트)** 382 | - 프로세스가 페이지를 요청했을 때 그 페이지가 메모리에 없는 상황 383 | ![페이징 매칭](https://user-images.githubusercontent.com/55946791/81517925-613cfe80-9377-11ea-99e8-35dcce20fb79.jpg) 384 | ex) 프로세스가 페이지 4를 요청 했을때, 페이지 테이블에 유효비트1, 주소 필드값 1 이므로 __메모리에 없고 스왑영역__ 에 있다. 이것을 페이지 부재라한다 385 | 386 | - ex) 1,2,3 있을때 실제 메모리에 1,2 할당, 다음에 3할당하려면 빼고...반복 387 | 388 | **Thrashing(쓰레싱)** 389 | - 메모리에 __페이지 부재율이 높은것,__ 심각한 성능 저하를 초래 390 | - 하드디스크의 입출력이 너무 많아져서 잦은 페이지 부재로 작업이 멈춘 것 같은 상태 391 | - 재료를 창고->도마 or 도마->창고 옮기는 작업이 많아, 요리 못하는 상태 392 | 393 | **스레싱과 물리 메모리 크기** 394 | - __멀티프로그래밍 정도__ : 동시에 실행하는 프로그램의 수 395 | - 멀티프로그래밍 정도가 높으면 스레싱 발생 396 | - 메모리가 꽉차면, 397 | - cpu가 작업하는 시간 < 스왑영역으로 페이지 보내고, 새로운 페이지 가져오는 작업 시간 398 | - cpu가 작업할 수 없는 상태 --> __스레싱 발생 지점__ 399 | ![멀티 프로그래밍 정도와 스레싱](https://user-images.githubusercontent.com/55946791/81518391-d9f08a80-9378-11ea-8a2c-196ae4ac0417.png) 400 | 401 | **물리 메모리 크기와 작업 속도** 402 | - 물리 메모리 용량을 512MB->4GB로 늘리면, 스레싱 발생 지점 늦춰져서 성능 향상 403 | - 물리 메모리 용량을 4GB -> 16GB로 늘리면 ? (물리 메모리가 작업하는데 충분한 크기면) 크기를 늘려도 작업 속도에 영향 미치지 X 404 | - 식탁 크기의 도마 -> 방 크기의 도마로 바꾼다해서 요리 시간이 빨라지지 X 405 | 406 | 407 | **스레싱과 프레임 할당** 408 | - 남아 있는 프레임을 실행 중인 프로세스에 적절히 나눠주는 정책 409 | - 프로세스에 너무 적은 프레임 할당시, 페이지 부재 빈번 410 | - 너무 많은 프레임 할당시, 페이지 부재 少, 메모리 낭비 411 | --> 각 프로세스가 필요로 하는 최소한의 프레임 갯수를 보장해줘야 한다. 412 | 413 | - 정적할당 414 | - 동적할당 415 | 416 | > [참고](https://jwprogramming.tistory.com/56) 417 | > [참고 - 쉽게 배우는 운영체제] 418 | 419 | ## 프로세스간 통신하는 방법은? 420 | 421 | ![프로세스간 통신](https://user-images.githubusercontent.com/55946791/81771876-237ada00-951f-11ea-8ef9-e12e862dd5e4.jpg) 422 | 423 | 프로세스간 통신(IPC, Inter Process Communication) 424 | 425 | - 정의 : 하나의 컴퓨터 안에서 실행중인 서로 다른 프로세스 간 발생하는 통신 426 | - 기능 : 의사 소통 기능 & 동기화를 보장해야 한다. 427 | - 동기화 : 하나의 프로세스가 공유 데이터 값을 변경하는 동안 , 다른 프로세스는 그 데이터에 접근 x 428 | - 종류 : 메시지 전달(message passing) & 공유 메모리(shared memory) / __공유 변수 사용 여부에__ 나뉜다 429 | 430 | **1.메시지 전달** 431 | - 특징 : ipc를 위해 __커널을 통해__ 메세지를 전달하는 방식으로 자원,데이터 주고받는다 432 | - 장점 : 별도의 구축없이 커널을 이용하기 때문에 비교적 구현이 쉽다 433 | - 단점 : 커널을 이용하기 때문에, __시스템 콜__이 필요하며 이로 인해 __오버헤드가__ 발생 434 | - 종류 : __파이프, 메시지 큐, 소켓, 시그널 등__ 435 | 436 | **1-1.메시지 전달 모델 - 파이프** 437 | - 특징 : 하나의 프로세스가 파이프를 통해 다른 프로세스로 메시지를 직접 전달 438 | - 단점 : __단방향 통신__ , 따라서 2개의 프로세스 통신시, 2개 파이프 필요 -> 100개 프로세스 통신시, 100P2 = 9900개 필요하므로 __자원 낭비가 심하다__ 439 | - 종류 : 익명파이프, 네임드 파이프 440 | 441 | **익명파이프** 442 | - 사용에 제한이 있다. 443 | - 이름이 없기 때문에 __외부 프로세스에서 이 파이프 호출불가__ 444 | - 부모, 자식 프로세스 간 통신시 사용 445 | 446 | **네임드파이프** 447 | - 이름이 있기 때문에 __외부 프로세스와 통신 가능__ 448 | 449 | **1-2.메시지 전달 모델 - 메시지 큐** 450 | - 특징 : 고정 크키의 메시지를 연결 리스트를 통해 통신하는 방식 451 | - 메시지 단위의 통신, 메시지 큐id를 통해 통신 452 | 453 | **1-3.메시지 전달 모델 - 소켓** 454 | - 특징 : 네트워크 상에서 프로세스간 통신, local&remote 통신가능 455 | 456 | 457 | **2.공유 메모리** 458 | - 특징 : ipc를 위해 __공유 메모리 영역__ 을 구축하고, 공유 영역을 통해 자원이나 데이터를 주고 받는다. 459 | - 장점 : 커널 의존성이 낮기 때문에 __속도가 빠르다__ , 유저 레벨에서 ipc가 가능하기 때문에, __통신이 자유롭다__ 460 | - 단점 : 자원과 데이터를 __공유하기 때문에 동기화!!!__ 이슈 발생. 461 | 462 | 463 | 464 | ## 32bit CPU와 64bit CPU의 차이 465 | 466 | bit : CPU가 처리하는 데이터의 최소 단위(레지스터)의 크기 467 | - 32bit/64bit CPU는 한 번에 다룰 수 있는 데이터의 최대 크기가 32bit/64bit 468 | - CPU 내부 부품은 비트를 기준으로 제작된다. 469 | - 32bit CPU 내의 레지스터 크기, 산술 논리 연산장치, 버스의 크기, 대역폭 모두 32bit 470 | - 메모리 주소 레지스터(MAR, 메모리 주소를 지정하는 레지스터) 크기가 32bit 이므로 표현 할 수 있는 메모리 주소의 범위가 0~2의32승, 총 크기는 2의32승bit, 약 4GB이다 471 | 472 | **차이점** 473 | - 32bit CPU컴퓨터는 최대 4GB의 메모리까지만 사용 가능하다 474 | - 64bit CPU컴퓨터는 4GB이상의 메인 메모리를 사용가능 475 | 476 | 477 | ## 장기/단기/중기 스케줄러에 대해 설명해라 478 | ![스케줄라](https://user-images.githubusercontent.com/55946791/81558928-80fd1280-93c9-11ea-9c86-f50c267ec647.jpg) 479 | 480 | 481 | **장기 스케줄러(잡 스케줄러)** 482 | - 메모리와 디스크 사이에서 메모리에(Ready Queue)에 어떤 걸 집어넣을지 결정 483 | - 하드디스크에서 메인 메모리로 로드하는것은 꽤 느린 작업이므로, 장기 스케줄러는 신중히 프로세스를 로드해야한다. 484 | - 입/출력을 많이하는 프로세스&cpu연산을 많이 하는 프로세스를 적절히 선택하여 메인 메모리로 로드하는 것이 중요 485 | - 하드디스크 -> 메인 메모리 486 | 487 | **단기 스케줄러(cpu 스케줄러)** 488 | - CPU와 메모리 사이에서 __Ready Queue에 있는 프로세스 중 어떤 것을 CPU 할당을 받게 할지__ 스케줄링 489 | - 메인 메모리 -> CPU 490 | 491 | **중기 스케줄러(Swapper)** 492 | - 여유공간 부족 시 공간을 만들기 위해 메모리에서 쫓아내어 하드 디스크로 옮김, 동시에 메모리가 많이 올라가는 것을 조절 493 | 494 | >[참고1](https://twinw.tistory.com/4) 495 | >[참고2](https://twinjh.tistory.com/18) 496 | 497 | ## 멀티프로세스와 멀티쓰레드는 무엇이고 어떤 차이가 있나요 498 | 499 | - 멀티프로세스 : 여러개의 프로세서를 이용해 여러개의 프로세스로 작업하는것 500 | - __문맥 교환시 오버헤드가 크다__ 501 | - 프로세스간 통신이 어렵다 502 | - 프로세스간 독립적이다 503 | 504 | - 멀티쓰레드 : 하나의 프로세서로 여러개의 쓰레드로 작업하는것 505 | - 스레드간 자원을 공유하기 때문에 506 | - 문맥교환시 __오버헤드가 적고,__ 스레드간 통신이 비교적 쉽고, 중복되는 자원을 줄일수있다. 507 | - 하지만, 동기화에 신경써야 하고, 하나의 스레드에 문제가 생기면 전체 스레드에 문제가 발생한다. 508 | 509 | ## 사용자 수준 쓰레드와 커널 수준 쓰레드란 무엇인가요 510 | 511 | **사용자 수준 스레드** 512 | - 스레드 교환에 커널이 개입하지않는다 513 | - 쓰레드와 관련된 행위를 유저쪽에서 한다 514 | - 장점 515 | - 스레드 전환 시 커널 스케줄러를 호출할 필요가 없기 때문에 516 | - 사용자 수준 스레드는 context swith가 비교적 적다 517 | - 따라서 커널 수준 스레드 보다 오버헤드가 작다 518 | - 스레드 스케줄러가 사용자 모드에만 존재한다 519 | - 단점 520 | - 프로세스 내의 한 스레드가 __(I/O요청)커널로 진입하는 순간 나머지 스레드는 전부 정지된다__ 521 | - 이는 커널이 스레드의 존재를 알지 못하기 때문에 발생하는 현상 522 | 523 | **커널 수준 스레드** 524 | 525 | -장점 526 | - 사용자 수준 스레드 보다 효율적이다 527 | - 커널 스레드를 쓰면 멀티프로세서를 활용할 수 잇는 장점이있다. 528 | - 사용자 스레드 cpu가 아무리 암ㅎ더라도 커널 모드의 스케줄이 되지 않으므로 cpu에 효율적으로 스레드를 배당할 수 없다 529 | -단점 530 | - 커널 스케줄러를 통해 context swith가 발생한다 531 | - 이 과정에서 프로세서 모드가 사용자 모드와 커널 모드 사이를 움직이기 때문에 빈번할 수록 성능 하락 532 | - 오버헤드가 많이 일어난다. 커널이 개입하기 때문에 533 | 534 | >[참고](https://geekhub.tistory.com/58) 535 | 536 | ## 동기화란 무엇이며 어떤 해결방법이 있나요 537 | - 동기화 538 | - __공유 자원에 대하여 동시에 접근하는 프로세스/스레드들로 인해 발생하는 문제를 해결하기 위해 행하는 방식__ 539 | 540 | - 경쟁 상태 (Race Condition) : 541 | 경쟁 상태란 두 개 이상의 프로세스 혹은 스레드가 공유 자원을 동시에 사용할 때 그 순서에 따라 결과가 달라지는 문제. 542 | 은행 잔고를 예제로 들면 은행 잔고라는 공유 데이터를 읽어와서 입금 연산과 출금 연산을 하는데, 동시에 접근해서 연산해버리면 한 쪽 연산이 반영이 안되는 문제 543 | 544 | - 임계영역과 크리티컬 섹션 : 545 | 사전상으로는 같은 말이지만, 의미하는 바가 다를 수 있다. 546 | 임계영역은 프로세스간 자원이 공유될 수 있는 코드 블록을 의미하며, 크리티컬 섹션은 하나의 동기화 방법을 말한다. 임계 영역을 프로세스들이 같이 쓸 수 있는 전제 조건은 다음과 같다. 547 | 548 | - 상호 배제 (Mutal Exculsion) : 프로세스가 크리티컬 섹션에 들어가 있다면, 다른 프로세스는 크리티컬 섹션에 들어갈 수 없다. 549 | - 진행 (Progress) : 크리티컬 섹션에 들어가 있는 프로세스가 없다면 다른 후보 프로세스가 진입할 수 있다. 550 | - 한정된 대기 (Bounded Waiting) : 프로세스가 진입 가능한 횟수에는 제한이 있다(특정한 한 프로세스만 계속 진입하는 것을 방지). 551 | 552 | - Lock : 553 | 하드웨어 기반 처리로, 임계 영역에 진입하기 위해서는 Lock이 필요하다. 임계 영역에 들어가는 프로세스는 Lock을 획득하고, 빠져나올때 Lock을 반납한다. 다중 처리기 환경에서 성능을 보장할 수 없다. 554 |
555 | 556 | **세마포어** 557 | 558 | - 바쁜대기 해결 559 | - 연산 방법 : 560 | 561 | ``` 562 | - P : 검사(Proberen), 프로세스를 대기시키는 'wait 동작'으로 임계영역에 진입하기 위한 연산 563 | - P(S) : while S <= O do no-op; 564 | 565 | - S := S - ; 566 | 567 | - V : 증가(Verhogen), 대기 중인 프로세스를 '깨우는 신호를' 보내는 signal 동작으로 임계영역에 나오기 위한 연산 568 | - V(S) : S := S + 1; 569 | ``` 570 | 571 | - 문제점 : 572 | - 1. p나v 실행 안되면 , 데드락 발생 573 | - 2. v실행후 2개이상의 프로세스 동시 접근시, 상호배제 보장x 574 | 575 | - 종류 : OS는 카운팅/이진 세마포어를 구분한다. 576 | - 카운팅 세마포어 : 동시에 사용가능한 자원에 대해 사용되며, 임계영역 안에 스레드나 프로세스가 들어오면 카운트를 증가시켜, 일정 숫자만큼의 스레드만 사용하게 하는 것 577 | - 이진 세마포어 : 0과 1로만 된 세마포어로, 임계영역 안에 하나의 프로세스만 들어갈 수 있다. 뮤텍스라고도 함. 578 | 579 | 580 | **모니터** 581 | - 락을 얻고 해제하는 부분이 자동으로 된다는 점만 빼고는 거의 세마포어와 비슷하다. 582 | 583 | 584 | **Busy Waiting** 585 | - 멀티 쓰레드 환경에서, 공유자원을 사용할때 기다리는 쓰레드가 __공유 자원을 사용할수 있는지 계속해서 무한 루프를 돌면서 조건문을 체크하는__ 방식 586 | - 임계 영역에 진입하려는 프로세스는 계속해서 진입하는 코드를 실행해야 한다. 따라서 성능의 저하가 발생할 수 있음. 587 | - 세마포어에서도 데드락이 발생할 수 있다. 588 | 589 | ## 멀티프로세싱, 멀티프로그래밍, 멀티스레딩, 멀티태스킹 590 | - CPU 코어의 관점에서 생각 591 | 592 | **멀티 프로세싱** 593 | - CPU N 프로세스 N 수행 (멀티 프로세스X, 멀티 프로세서O) 594 | 595 | **멀티 쓰레딩** 596 | - CPU 1, 쓰레드 N 수행 597 | 598 | **멀티 프로그래밍** 599 | - CPU 1 프로세스 N 수행 600 | - 프로세스 A에 대해서 프로세서가 작업(ex io작업)을 처리할때 낭비되는 시간동안 다른 프로세스를 처리하도록 하는 것 입니다. 601 | - __CPU의 자원이 낭비되는 것을 최소화__ 602 | 603 | **멀티 태스킹** 604 | - 다수의 TASK(프로세스보다 조금더 확장된 개념)를 운영체제의 스케줄링에 의해 번갈아가면서 수행하는것 605 | - __일정하게 정해진 시간동안 번갈아가면서 각각의 Task를 처리하는 것__ 606 | - job > task > thread, 여러 스레드가 모인것이 태스크 607 | 608 | 609 | ## 톰캣은 멀티 프로세스인가 멀티 스레드인가 610 | - WAS 611 | 612 | ## 아파치는 멀티 프로세스인가 멀티 스레드인가 613 | - WS 614 | - 멀티프로세스, 스레드 둘다있다 615 | 616 | ## 동기, 비동기, 블로킹, 넌블로킹 차이 617 | 618 | **동기** 619 | - 어떤 일에 대한 요청과 응답(혹은 입출력)이 __동시에 이루어져야__ 하는 것 620 | - call하고 응답이 올 때까지 기다렸다가 다음 로직을 실행한다. 621 | * 장점 : 안전성이 보장된다. 순서가 보장된다. 622 | * 단점 : 느리다. 623 | 624 | **비동기** 625 | - 어떤 일에 대한 요청과 응답이 __동시에 이루어질 필요 없이__ 따로 이루어지는 것. 626 | - call하고 응답이 오지 않아도 다음 로직을 실행한다. 627 | * 장점 : 빠르다 628 | * 단점 : 처리 하기가 까다롭다. 순서가 보장이 되지 않는다. 629 | 630 | 631 | **블로킹** 632 | - 어떤 요청에 대한 __응답이 올 때까지 대기__ 하는 것. 633 | - 즉 동기를 위해서는 블로킹 되어야 함 634 | 635 | **넌블로킹** 636 | - 어떤 요청에 대해서 응답을 대기하지 않고 계속 루틴을 수행하는 것. 637 | - 비동기를 위해서는 넌블로킹 되어야 하지만, 넌블로킹이 비동기는 아니다(포함관계라고 생각하면 될 듯) 638 | - 예를 들어 넌블로킹이면서, 요청에 대한 응답을 계속해서 요구하는 폴링 방식의 경우, 비동기라 보기는 힘들다. 639 | - 이벤트 핸들러나 인터럽트를 통해 응답을 받는 것이 비동기 모델. 640 | 641 | ### 스레드와 프로세스의 차이 642 | 643 | |프로세스|스레드| 644 | |--|--| 645 | |요리작업전체 | 각각의 조리| 646 | |os입장에서 작업단위 | cpu입장에서 작업단위| 647 | | 프로세스간 약하게 연결 | 스레드간 강하게 연결| 648 | | 프로세스간 독립적 | 코드, 데이터, 힙 영역 공유| 649 | 650 | **프로세스** 651 | ![process](https://user-images.githubusercontent.com/55946791/81820714-ed177c00-956b-11ea-8abb-59bff294c65a.png) 652 | 653 | - 프로그램이 메모리에 올라와 OS로부터 자원을 할당받은 것 654 | - 다른 프로세스 __메모리에 직접 접근 불가__ (공유메모리나 커널을이용해서 메시지전달 ) 655 | 656 | - __문맥교환__ : cpu에서 여러 프로세스를 돌아가면서 작업을 처리하는 과정(현재 프로세스상태 보관, 다음 프로세스상태 복구하는 작업) 657 | 658 | **스레드** 659 | ![thread](https://user-images.githubusercontent.com/55946791/81820709-ebe64f00-956b-11ea-828d-36b063c1fced.png) 660 | - 프로세스 내에서 실행되는 흐름의 단위를 말한다 661 | - 프로세스 내에서 스레드끼리 주소공간이나 자원들을 공유하면서 실행 (code, data, heap 공유) 662 | - 장점 : 663 | - 불필요한 __자원 중복 없앤다__ : 시스템 효율 향상 664 | - 프로세스간 통신보다 스레드간 __통신이 쉽다__ 665 | - 자원을 공유하므로 문맥교환시 오버헤드가 적다 666 | 667 | - 단점 668 | - 자원을 공유하므로 __동기화__ 에 유의해야한다. 669 | - 한 스레드에 문제가 생기면 전체 프로세스에 영향(익스플로러는 문제 생기면 모두종료 / 크롬은 멀티프로세스여서 모두 종료x) 670 | 671 | >[참고](https://gmlwjd9405.github.io/2018/09/14/process-vs-thread.html) 672 | -------------------------------------------------------------------------------- /contents/software-engineering.md: -------------------------------------------------------------------------------- 1 | # 9. Software Engineering 2 | **:book: Contents** 3 | * [sw공학이란? 필요한 이유? 좋은 설계란?](#sw공학이란?-필요한-이유?-좋은-설계란?) 4 | * [형상관리란?](#형상관리란?) 5 | * [Singleton, Adapter, Template패턴은 어떤 것인가? 왜 사용하는지? 코드 구현해보시오](#Singleton,Adapter,Template패턴은-어떤-것인가?-왜-사용하는지?-코드-구현해보시오) 6 | * [코드 결합도와 응집도란?](#코드-결합도와-응집도란?) 7 | * [블랙박스/화이트박스 테스트란?](#블랙박스/화이트박스-테스트란?) 8 | 9 | 10 | * [Agile 방법론이 무엇인지 설명해주세요](#Agile-방법론이-무엇인지-설명해주세요) 11 | * [소프트웨어 생명 주기 모델은 무엇이고 어떤 모델이 있는지 설명해주세요](#소프트웨어-생명-주기-모델은-무엇이고-어떤-모델이-있는지-설명해주세요) 12 | * [CVS, SVN, GIT에 대해서 아는대로 설명해 보시오] 13 | * [형상 관리를 잘못하면 어떤 문제가 발생하나요?] 14 | * [객체지향과 절차지향 차이 설명해주세요] 15 | 16 |
17 | 18 | * [MVP패턴, MVVM패턴이란?](#MVP패턴,-MVVM패턴이란?) 19 | * [TDD란?](#TDD란?) 20 | * [Java에서 Builder 패턴을 사용하는이유는?](#Java에서-Builder-패턴을-사용하는이유는?) 21 | * [Observer 패턴은?](#Observer-패턴은?) 22 | * [Java에서 팩토리 메서드 패턴을 사용하는 이유는?](#Java에서-팩토리-메서드-패턴을-사용하는-이유는?) 23 | 24 | --- 25 | ## sw공학이란? 필요한 이유? 좋은 설계란? 26 | 27 | **sw공학이란?** 28 | - sw의 설계, 개발, 유지보수 등에 대한 체계적인 이론과 기술 29 | 30 | **필요한 이유?** 31 | - 시간이 지날수록 sw의 수요는 늘었지만 sw의 개발은 여전히 어렵고 힘들어 여러 가지 문제점이 나타나기 시작했다 32 | - 유지보수나 확장등의 문제를 해결하기 위해 sw공학이 필요하다. 33 | 34 | **좋은 설계란?** 35 | - 요구사항 명세서의 모든 내용을 포함 36 | - 유지 보수시 변경이 용이 37 | 38 | > :arrow_double_up:[Top](#9-Software-Engineering) :leftwards_arrow_with_hook:[Back](https://github.com/devham76/tech-interview-studyw#9-Software-Engineering) :information_source:[Home](https://github.com/devham76/tech-intervie-studyw#tech-interview) 39 | 40 | ## 형상관리란? 41 | - sw의 변경사항을 체계적으로 추적하고 통제하는 것 42 | - 프로젝트와 관련된 모든 변경사항을 관리한다 43 | - 형상 관리 도구 : CVS, SVN, Git 등이 있다 44 | 45 | > :arrow_double_up:[Top](#9-Software-Engineering) :leftwards_arrow_with_hook:[Back](https://github.com/devham76/tech-interview-studyw#9-Software-Engineering) :information_source:[Home](https://github.com/devham76/tech-intervie-studyw#tech-interview) 46 | 47 | 48 | ## Singleton,Adapter,Template패턴은 어떤 것인가? 왜 사용하는지? 코드 구현해보시오 49 | 50 | **Singleton 패턴** 51 | - 생성자가 여러 차례 호출되더라도 실제 생성되는 객체는 하나이고 52 | 최고 생성 이후 호출된 생성자는 최초 생성자가 생성한 객체를 리턴한다 53 | - DBCPC(DataBase Connetcion Pool)과 같은 상황에서 많이 사용된다 54 | - 왜 사용하나요? 55 | 56 | **구현** 57 | - 생성자를 외부에서 호출할수 없게 private으로 선언한다 58 | - 인스턴스 생성을 내부에서 처리하여 외부에서는 그것을 가져다가 쓰기만 하도록한다 59 | > [참고](https://gmlwjd9405.github.io/2018/07/06/singleton-pattern.html) 60 | 61 | **Adapter 패턴** 62 | ![adapter patteren](https://user-images.githubusercontent.com/55946791/81135809-8bb44380-8f94-11ea-9b96-8af9af1cdb66.png) 63 | 64 | - 한 클래스의 인터페이스를 사용하고자 하는 다른 인터페이스로 변환한다. 65 | - 어댑터를 이용하면 인터페이스 호환성 문제 때문에 같이 쓸 수 없는 클래스들을 연결해서 쓸수 있다. 66 | 67 | > [참고](https://niceman.tistory.com/141) 68 | 69 | **Template 패턴** 70 | - public final 메소드(HoustTemplate.buildHouse())에서 알고리즘의 골격을 정의한다. 71 | - 알고리즘의 여러 단계 중 일부는 서브 클래스(WoodenHouse.java, GlassHouse.java)에서 구현할 수 있다. 72 | - 템플릿 메소드를 이용하면 알고리즘의 구조는 그대로 유지하면서 서브클래스에서 특정 단계를 재정의 할 수 있다. 73 | 74 | ![template method 패턴](https://user-images.githubusercontent.com/55946791/81136309-2b260600-8f96-11ea-892a-41016e775907.JPG) 75 | 76 | > [참고](https://niceman.tistory.com/142?category=940951) 77 | 78 | > :arrow_double_up:[Top](#9-Software-Engineering) :leftwards_arrow_with_hook:[Back](https://github.com/devham76/tech-interview-studyw#9-Software-Engineering) :information_source:[Home](https://github.com/devham76/tech-intervie-studyw#tech-interview) 79 | 80 | 81 | ## 코드 결합도와 응집도란? 82 | **결합도** 83 | 모듈간의 연결되어 상호 의존하는 정도 84 | 결합도가 약할수록 좋은 설계 85 | 86 | **응집도** 87 | 모듈 안의 요소들이 서로 관련되어 있는 정도 88 | 응집도가 강할수록 좋은 설계 89 | 90 | > [참고](https://chayan-memorias.tistory.com/90) 91 | 92 | > :arrow_double_up:[Top](#9-Software-Engineering) :leftwards_arrow_with_hook:[Back](https://github.com/devham76/tech-interview-studyw#9-Software-Engineering) :information_source:[Home](https://github.com/devham76/tech-intervie-studyw#tech-interview) 93 | 94 | 95 | ## 블랙박스/화이트박스 테스트란? 96 | **화이트 박스 검사** 97 | - sw 내부 코드를 테스트 하는 기법 98 | - 개발자 관점의 내부 구조와 동작을 테스트 하는 방법 99 | 100 | **블랙 박스 검사** 101 | - sw내부 구조나 작동 원리를 모르는 상태에서 동작을 검사하는 방법 102 | 103 | > [참고](https://kkhipp.tistory.com/158) 104 | > :arrow_double_up:[Top](#9-Software-Engineering) :leftwards_arrow_with_hook:[Back](https://github.com/devham76/tech-interview-studyw#9-Software-Engineering) :information_source:[Home](https://github.com/devham76/tech-intervie-studyw#tech-interview) 105 | 106 | ## Agile 방법론이 무엇인지 설명해주세요 107 | **애자일 방법론** 108 | 일정한 주기를 가지고 끊임없이 프로토 타입을 만들어 내며, 그때그때 필요한 요구를 더하고 수정하여 하나의 커라단 소프트웨어를 만들어 내는 소프트웨어 개발 방법론인 Agile 개발 방법론 채택 109 |
110 | 일정 주기를 가지고 계속 프로토 타입을 만들면서 요구사항을 필요할때마다 추가하고 수정하면서 큰 프로그램을 만들어 나아가는 겁니다. 111 | 1~2주나 3~4주 단위로 쪼개서 개발합니다. 112 | 이런게 많아지자 이를 지원하는 소프트웨어도 생겨났습니다. 113 | Jira같은 것이 있죠. 하지만 장점만 있는 건 아닙니다. 너무 개발자 중심이고, 수정이 가능하다에서 무한 수정이 될 수 있습니다. 114 | 시너지가 있을 수도 있지만 그에 대한 부작용도 많을 수 있습니다. 115 | > [참고](http://blog.naver.com/PostView.nhn?blogId=potter777777&logNo=220784755910) 116 | 117 | **애자일 방법론의 장점** 118 | - 프로젝트 진행 중간 중간에 필요한 요소들을 바꿀 수 있습니다. 119 | - 시작할 때 프로젝트를 정확하게 규정하지 않아도 됩니다. 120 | - 작은 요소들을 출시 할 때 빠르게 만들 수 있습니다. 121 | - 점진적으로 테스트되기 때문에 초기에 버그를 발견할 수 있습니다. 122 | 123 | 124 | > [참고](https://flearning-blog.tistory.com/233) 125 | 126 | > :arrow_double_up:[Top](#9-Software-Engineering) :leftwards_arrow_with_hook:[Back](https://github.com/devham76/tech-interview-studyw#9-Software-Engineering) :information_source:[Home](https://github.com/devham76/tech-intervie-studyw#tech-interview) 127 | 128 | ## 소프트웨어 생명 주기 모델은 무엇이고 어떤 모델이 있는지 설명해주세요 129 | 130 | **생명 주기 모델** 131 | -소프트웨어를 어떻게 개발할 것인가에 대한 추상적 표현 132 | - 프로젝트 비용 산정과 개발 계획 수립의 기본 골격 133 | - 요구사항 분석(정의) -> 개발(설계, 구현, 테스트) -> 유지보수 134 | 135 | **모델 종류** 136 | 1. 폭포수 모델 137 | - 선형 순차적, 처음부터 사용자들이 요구사항 명확하게 제시해야한다 138 | - 요구사항이 이해하기 쉽고, 시스템 개발 중 급격한 변경이 없는 경우 효과적 139 | 140 | 2. 프로토 타입 모델 141 | - 포르토타입 모델 제시 142 | 143 | 3. 나선형 모델 144 | - 폭포수 개선 + 프로토타입 모델의 반복성 + 위험분석 145 | - 대규모 프로젝트에 적합 146 | - 여러 차례 개발 과정 반복 147 | 148 | > [참고](https://storyofsol.tistory.com/124) 149 | 150 | > :arrow_double_up:[Top](#9-Software-Engineering) :leftwards_arrow_with_hook:[Back](https://github.com/devham76/tech-interview-studyw#9-Software-Engineering) :information_source:[Home](https://github.com/devham76/tech-intervie-studyw#tech-interview) 151 | 152 | ## CVS, SVN, GIT에 대해서 아는대로 설명해 보시오 153 | 154 | - CVS (Concurrent Version System) 155 | - 90년에 출시된 무료 서버-클라이언트 형상관리 시스템. 156 | - 파일 전체를 저장하는 것이 아니라 __변경사항만을 저장함__ 으로 용량을 적게 차지하지만 157 | - 속도가 상대적으로 느리다. 158 | 159 | - SVN (Subversion) 160 | - 형상관리/소스관리 툴의 일종. 161 | - 중앙관리만을 지원. 162 | - 다른 사용자의 커밋과 엉키지 않으며, 커밋 실패 시 롤백 기능을 지원. 163 | - 안정성에 있어 CVS보다 상대적으로 좋지 않다. 164 | 165 | - Git 166 | - 분산형 버전관리 시스템 167 | - Repository의 완전한 복사본을 로컬에 저장할 수 있다. 168 | - 처리속도가 빠르지만 대용량 코드 관리에 부적절하다. 169 | 170 | > [참고](https://velog.io/@rxjw95/SE) 171 | 172 | > :arrow_double_up:[Top](#9-Software-Engineering) :leftwards_arrow_with_hook:[Back](https://github.com/devham76/tech-interview-studyw#9-Software-Engineering) :information_source:[Home](https://github.com/devham76/tech-intervie-studyw#tech-interview) 173 | 174 | ## 형상 관리를 잘못하면 어떤 문제가 발생하나요? 175 | 176 | 대규모 프로젝트는 수십, 수백명의 인원이 소프트웨어를 함께 개발하는데 그에 맞는 표준이 존재하지 않고 서로의 개발 사항을 확인하지 못한다면 프로젝트의 위험이나 혼란이 발생할 수 있음 177 | 178 | ``` 179 | 대규모 프로젝트에서는 발생 가능한 위험이나 혼란을 줄이고 프로젝트를 체계적으로 관리하기 위해 형상관리가 반드시 필요 180 | ``` 181 | 182 | > [참고](https://velog.io/@rxjw95/SE) 183 | 184 | > :arrow_double_up:[Top](#9-Software-Engineering) :leftwards_arrow_with_hook:[Back](https://github.com/devham76/tech-interview-studyw#9-Software-Engineering) :information_source:[Home](https://github.com/devham76/tech-intervie-studyw#tech-interview) 185 | 186 | ## 객체지향과 절차지향 차이 설명해주세요 187 | <<<<<<< HEAD 188 | 189 | **절차지향 프로그래밍** 190 | - 실행하고자 하는 절차를 정하고, 이 절차대로 프로그래밍하는 방법 191 | 목적을 달성하기 위한 일의 흐름에 중점을 둔다. 192 | 193 | - 장점 : 객체지향보다 속도가 빠르다 194 | 195 | **객체지향 프로그래밍** 196 | 197 | - 실세상의 물체를 객체로 표현하고, 이들 사이의 관계, 상호 작용을 프로그램으로 나타낸다. 198 | 199 | - __객체를 추출하고 객체들의 관계를 결정__ 하고 이들의 __상호 작용에__ 필요한 함수(메서드)와 변수(필드)를 설계 및 구현하다. 200 | 201 | - 객체 지향의 행심은 연관되어 있는 변수와 메서드를 하나의 그룹으로 묶어서 그룹핑하는 것이다. 202 | 203 | - 사람의 사고와 가장 비슷하게 프로그래밍을 하기 위해서 생성된 기법 204 | 205 | - 하나의 클래스를 바탕으로 서로 다른 상태를 가진 인스턴스를 만들면 서로 다른 행동을 하게 된다. 즉, 하나의 클래스가 여러 개의 인스턴스가 될 수 있다는 점이 객체 지향이 제공하는 가장 기본적인 재활용성이라고 할 수 있다. 206 | 207 | - 단점 : 설계에 많은 시간 208 | - 장점 : 유지보수에 좋다. 큰 프로젝트에 적합하다 209 | 210 | 211 | **객체지향 프로그래밍과 절차지향 프로그래밍의 차이** 212 | - 절차지향 프로그래밍 213 | 214 | 실행하고자 하는 절차를 정하고, 이 절차대로 프로그래밍하는 방법 215 | 목적을 달성하기 위한 __일의 흐름에 중점을__ 둔다. 216 | 217 | - 객체지향 프로그래밍 218 | 219 | __실세상의 물체를 객체로 표현하고, 이들 사이의 관계, 상호 작용을 프로그램으로 나타낸다.__ 220 | 객체를 추출하고 객체들의 관계를 결정하고 이들의 상호 작용에 필요한 함수(메서드)와 변수(필드)를 설계 및 구현하다. 221 | 객체 지향의 행심은 연관되어 있는 변수와 메서드를 하나의 그룹으로 묶어서 그룹핑하는 것이다. 222 | 사람의 사고와 가장 비슷하게 프로그래밍을 하기 위해서 생성된 기법 223 | 하나의 클래스를 바탕으로 서로 다른 상태를 가진 인스턴스를 만들면 서로 다른 행동을 하게 된다. 즉, 하나의 클래스가 여러 개의 인스턴스가 될 수 있다는 점이 객체 지향이 제공하는 가장 기본적인 재활용성이라고 할 수 있다. 224 | 225 | > [참고1](https://gmlwjd9405.github.io/2017/10/01/basic-concepts-of-development-java.html) 226 | > [참고2](https://gbsb.tistory.com/3) 227 | 228 | > :arrow_double_up:[Top](#9-Software-Engineering) :leftwards_arrow_with_hook:[Back](https://github.com/devham76/tech-interview-studyw#9-Software-Engineering) :information_source:[Home](https://github.com/devham76/tech-intervie-studyw#tech-interview) 229 | 230 | 231 | ## MVP패턴, MVVM패턴이란? 232 | 모바일과 관련된 233 | controller가 사용자 입력 234 | view가 처리. presenter에게 전달 235 | 단점 ; view와 presenter 1:1 대응이여서 코드가많아지고, 의존성이 높아져서 236 | 237 | 보완하기 위해 나온것이 mvvp 238 | 239 | view가 변경되면 변경된 view model을 이용한다 240 | 데이터바인딩을 이용해서 view model을 만든다 241 | 단점 ; view를만들기 어렵다 242 | 243 | >[참고](https://beomy.tistory.com/43) 244 | 245 | > :arrow_double_up:[Top](#9-Software-Engineering) :leftwards_arrow_with_hook:[Back](https://github.com/devham76/tech-interview-studyw#9-Software-Engineering) :information_source:[Home](https://github.com/devham76/tech-intervie-studyw#tech-interview) 246 | 247 | ## TDD란? 248 | - Test Driven Development 249 | - 테스트 주도 개발 : __테스트가 개발을 이끌어 나간다__ 250 | - 개념 251 | - 테스트를 먼저 만들고 테스트를 통과하기 위한 코드를 작성하는 것. 252 | - 레드 그린 사이클 (TDD사이클) 253 | 1. RED 항상 실패하는 테스트를 먼저 작성하고 254 | 2. GREEN 테스트가 통과하는 프로덕션 코드를 작성하고 255 | 3. Refactor 테스트가 통과하면 프로턱션 코드를 리팩토링한다 256 | (리팩토링 : 작동하는것은 그대로 놓고, 내부구현(코드)만 변경한다) 257 | 258 | - TDD를 하는이유 : __테스트와 개발을 같이 진행하여 개발 초기의 오류를 발견하고, 수정하여__ 좋은 소프트웨어를 개발하기 위한 방법 259 | - 단점 : 개발시간이 오래걸린다 260 | 261 | > [참고](https://devham76.github.io/testcode/Spring-testCode/) 262 | 263 | > :arrow_double_up:[Top](#9-Software-Engineering) :leftwards_arrow_with_hook:[Back](https://github.com/devham76/tech-interview-studyw#9-Software-Engineering) :information_source:[Home](https://github.com/devham76/tech-intervie-studyw#tech-interview) 264 | 265 | ## Java에서 Builder패턴을 사용하는이유는? 266 | - .builder 267 | - 생성자 매게변수가 많으면 유리 268 | > :arrow_double_up:[Top](#9-Software-Engineering) :leftwards_arrow_with_hook:[Back](https://github.com/devham76/tech-interview-studyw#9-Software-Engineering) :information_source:[Home](https://github.com/devham76/tech-intervie-studyw#tech-interview) 269 | 270 | ## Observer 패턴은? 271 | - 느슨한 결합도 제공 272 | > :arrow_double_up:[Top](#9-Software-Engineering) :leftwards_arrow_with_hook:[Back](https://github.com/devham76/tech-interview-studyw#9-Software-Engineering) :information_source:[Home](https://github.com/devham76/tech-intervie-studyw#tech-interview) 273 | 274 | ## Java에서 팩토리 메서드 패턴을 사용하는 이유는? 275 | - 276 | > :arrow_double_up:[Top](#9-Software-Engineering) :leftwards_arrow_with_hook:[Back](https://github.com/devham76/tech-interview-studyw#9-Software-Engineering) :information_source:[Home](https://github.com/devham76/tech-intervie-studyw#tech-interview) 277 | -------------------------------------------------------------------------------- /contents/spring.md: -------------------------------------------------------------------------------- 1 | # 8. Spring 2 | **:book: Contents** 3 | * IOC 란? 4 | * DI 란? 5 | * AOP 란? 6 | * 흐름(웹브라우저에서 Spring MVC로 요청했을 떄) 7 | * Bean 객체란? 8 | * 스프링 디스패처 서블릿이란 9 | * MVC1과 MVC2 패턴의 차이 10 | * Bean 생성 원리 11 | * Spring에서 AOP를 구현하는 3가지 방법. 12 | * Spring을 쓰는 이유 13 | 14 | 15 | * 스프링 버전 몇 사용하셨나요? (버전별 차이) 16 | * 스프링 security 사용해봤나요? 17 | 18 | --- 19 | 20 | ## IOC 란? (대신해줌) 21 | - Inversion Of Control, 제어의 역행이라는 뜻 22 | - __인스턴스의 생성 및 소멸을__ 개발자 대신 __스프링 컨테이너가__ 한다. 23 | - 따라서 __낮은 결합도를 유지한다__ 24 | - 사용안한다면 ,객체 사이의 의존관계를 개발자가 직접 코딩하지 않으므로 25 | - __코드에 의존관계가 명시되지 않아 결합도가 떨어져__ 유지보수 하기 좋다 26 | - IoC는 Spring외에서도 사용된다 27 | 28 | > 29 | 30 | ## DI 란? (미리 찜해 놓음) 31 | - Dependency Injection, 의존성 주입이라는 뜻으로, IOC를 실제로 구현하는 방법. 32 | - 객체사이의 의존관계를 __코드로 명시하는 것이 아니라__ 스프링 설정 파일에 등록된 정보를 바탕으로 __컨테이너가 자동으로 처리__ 해준다. 33 | - XML파일을 통해 설정한대로, Bean객체 생성시 의존성 주입을 수행한다. 34 | - 컨테이너가 직접 객체들 사이에 의존관계를 처리하는 것. 35 | 36 | ## AOP 란? 37 | - 관점지향 프로그래밍 (Aspect Orinted Programming) 38 | - __핵심 비즈니스 로직과__ (비즈니스 메소드마다 반복해서 등장하는) __공통 로직을 분리해서 응집도가 높게__ 개발할 수 있도록 지원한다. 39 | 40 | - 공통으로 사용하는 기능들을 외부로 독립된 클래스로 분리 41 | 42 | ### 컨테이너 43 | - 객체의 생성 관리를 담당하며, 객체 운용에 필요한 다양한 기능을 제공한다 44 | 45 | 46 | 47 | ## 흐름(웹브라우저에서 Spring MVC로 요청했을 떄) 48 | - spring mvc 흐름 49 | 1. 요청된 URL을 dispatcher-servlet에 전달 50 | 2. 핸들러 매핑은 해당 URL에 매핑된 컨트롤러가 있는지 검사 후 컨트롤러에 전달 51 | 3. 해당 컨트롤러가 로직을 처리 52 | 4. 결과를 ModelAndView 객체 생성 후 담아 dispatcher-servlet에 전달 53 | 5. dispatcher-servlet은 전달 받은 View(jsp)가 있는지 검사하기 위해 ViewResolver로 보냄 54 | 6. ViewResolver는 받은 View(jsp)가 있는 지 검사 후 View로 보냄 55 | 7. View에서 Model과 같이 View(jsp)를 그린 후에 dispatcher-servlet으로 전달 56 | 8. 최종적으로 컨텐츠를 클라이언트에게 전달. 57 | 58 | > 59 | 60 | ![spring-bean-scope](https://user-images.githubusercontent.com/55946791/81907235-6661ae00-9602-11ea-8e55-030820fee0b9.png) 61 | 62 | 1. DispatcherServlet : client로 부터 요청을 받는다 63 | 2. HandelerMapping : DispatcherServlet은 HandelerMapping을 통해서 요청을 처리할 Controller를 찾는다 64 | 3. Controller : Controller는 요청을 처리한다 65 | 4. 처리한 후에 이동할 화면정보를 리턴한다 66 | 5. ViewResolver : DispatcherServlet은 ViewResolver를 통해 접두사와 접미사가 붙은 JSP파일의 이름과 경로를 리턴받는다. 67 | 6. View : 최종적으로 JSP를 실행하고, 실행 결ㄹ과가 브라우저에 응답된다. 68 | 69 | 70 | 71 | ## Bean 객체란? 72 | - Spring에서 POJO(plain, old java object)를 ‘Beans’라고 부른다. 73 | - 스프링 __IoC컨테이너가 관리, 생성되는 객체__ 74 | - 컨테이너에서 생성되었다는 점을 제외하면 일반 자바객체와 같다. 75 | - __new를 통해 개발자가 생성한것은 Bean이 아니다__ 76 | - 이런 Bean들만 의존성이 주입된다 77 | - 빈 등록 방법 78 | - 애노테이션으로 빈임을 명시 (@Component, @Service, @Cotroller, @Repository, @Configuration) 79 | - xml이나 자바 설정파일에 등록 80 | - 빈 꺼내는 방법 81 | - @Autowired 사용 82 | 83 | **Spring Bean 정의** 84 | - 일반적으로 XML 파일에 정의한다. 85 | - 주요 속성 86 | - class(필수): 정규화된 자바 클래스 이름 87 | - id: bean의 고유 식별자 88 | - scope: 객체의 범위 (singleton, prototype) / (ex.@Scope("singleton")) 89 | - constructor-arg: 생성 시 생성자에 전달할 인수 90 | - property: 생성 시 bean setter에 전달할 인수 91 | - init method와 destroy method 92 | 93 | ![spring-bean-scope](https://user-images.githubusercontent.com/55946791/81903954-8773d000-95fd-11ea-8d07-246228465860.png) 94 | 95 | >[참고](https://gmlwjd9405.github.io/2018/11/10/spring-beans.html) 96 | 97 | ## Bean 생성 원리 98 | 스프링 부트에서는 @SpringBootApplication 어노테이션을 SpringBootApplication.run을 하는 메인 메소드가 있는 클래스 위에 붙이면 그 하위 패키지를 스캔한다. @SpringBootApplication 의 내부를 보면 @ComponentScan, @SpringBootConfiguration, @EnableAutoConfiguration 등의 어노테이션이 붙어있고 @ComponentScan 을 통해서 메인 메소드가 있는 클래스의 하위 패키지를 스캔하게 된다. 99 | 100 | 메인 메소드가 있는 클래스 하위의 @Bean, @Service, @Component, @Repo, @Controller... 등의 어노테이션이 붙은 클래스들을 빈 형태로 만들어서 빈 팩토리에서 관리하게 된다. 그리고 빈을 생성할 때 해당 빈 내부에 다른 주입이 필요한 빈이 있다면, 재귀적으로 하위에 있는 빈들을 처리하고 나서 빈을 생성후 관리하게 된다. 101 | 102 | ## Spring에서 AOP를 구현하는 3가지 방법. 103 | 104 | JDK Dynamic Proxy 생성 105 | Cglib 라이브러리 활용해 Proxy 생성 106 | AspectJ 라이브러리 활용 107 | 기존 스프링에서는 인터페이스가 있으면 JDK Dynamic Proxy를 사용하고(Java Reflection 이용), 인터페이스가 없으면 CGLib Proxy를 사용했었다.(바이트코드 조작) 이제 변경되어서 스프링 부트 내부적으로 빈 생성 시 디폴트로 Cglib 프록시로 생성하게 변경되었다. 108 | 109 | 이 CGLib프록시 객체를 이용해 Transaction이나 AOP가 작동하는 것이다. 110 | 111 | 만약 굳이 JDK Dynamic Proxy를 사용하고 싶으면 @EnableAspectjAutoProxt(proxyTargetClass = true) 를 주면 JDK Dynamic Proxy를 사용할 수 있다. 112 | 113 | AspectJ를 응용한 Compile Time Weaving도 가능하다. AspectJ를 사용하는 경우 Load Time Weaving도 가능하다. 114 | AspectJ는 실제 바이트 코드에 대한 변조이므로 제약조건이 가장 적고 성능도 가장 좋게 나온다. 115 | 주의해야 할 점: Spring AOP에서 @AspectJ 애노테이션을 사용하는 것은 AspectJ를 통한 compile time weaving을 수행하는 것이 아니다. JDK Dynamic Proxy / CGLib 기반 Runtime weaving 하에서 AspectJ의 문법만을 갖다 쓰는 것 에 불과하다. 116 | 117 | > [참고](https://tramyu.github.io/etc/interview/) 118 | 119 | ## Spring을 쓰는 이유 120 | - Spring 이전에는 EJB(Enterprise Java Beans)로 개발되었다. 121 | - EJB는 EJB컨테이너가 제공하는 많은 기술과 장점에도 불구하고 122 | 1. 스펙이 너무 복잡해서 __학습에 많은 시간이__ 필요하다 123 | 2. __개발 및 유지 보수하기에 복잡하고 힘들다__ 124 | 3. 툴의 도움없이는 다루기 힘든 난해할 설정, 까다로운 패키징, 불편한 서버 배치 등 때문에 -> __고가의 느리고 무거운 자바 서버가__ 필요했다. 125 | 4. EJB를 제대로 사용하려면 __디자인 패턴을 이해하고 적용할 수 있어야__ 한다. ( 성능 유지, 유지보수의 편의성을 위해) 126 | 127 | 128 | 129 | - 이를 보완하기 위해 나온것이 Spring이다 130 | 1. 평범한 POJO를 사용하면 EJB에서만 가능했던 많은 일을 가능하게 한다. 131 | 2. 스프링 프레임워크는 이미 많은 디자인 패턴이 적용되어 배포되므로 __프레임 워크를 사용하는 것 자체가 디자인 패턴을 사용하는것이다.__ 132 | 3. 톰캣같은 기본적인 웹서버로도 운영가능하다 133 | 134 |
135 | 136 | 엔터프라이즈 시스템 개발이 너무 복잡했다. 137 | - 비즈니스 로직 이외에도 고려할 사항이 많았다 138 | - 개발이 진행도미에 따라 로직이 복잡해지고, 잦은 변경 요구가 있었기 때문이다 139 | - 스프링은 복잡함을 해결하기 위해 DI,IoC,AOP,PSA의 특징을 가지고있다 140 | - IoC - 결합도 낮춰준다 141 | - AOP - 응집도 높혀준다 142 | 143 | >[참고](https://galid1.tistory.com/493) 144 | 145 | **POJO(Plain Old Java Object)** 146 | - __객체지향의 원리에 충실하면서__ 147 | - __환경과 기술에 종속되지 않고__ 148 | - 필요에 따라 재활용될수있는 방식으로 설계된 오브젝트 149 | - ex) Servlet 클래스는 POJO가 아니다. 150 | - 왜냐하면, 우리마음대로 만들수 없고 , 규칙에 맞게 만들어야하기 때문. 151 | 152 | ## 스프링 버전 몇 사용하셨나요? (버전별 차이) 153 | - springBootVersion 2.1.7 버전 사용해봤습니다. 154 | 155 | ### 2.3이전에는 156 | 스프링 부트 앱 만들면서 -> 웹이라는 모듈 추가하면 -> 웹이 vaildation 모듈 같이 가져왔다 157 | ###2.3부터 158 | 스프링 부트 앱 만들면서 -> 웹 추가해도 벨리데이션 모듈 가져오지 않는다 159 | 160 | ``` 161 | spring-boot-starter-validation은 기본적으로 가져오지 않는다 162 | -> 객체가 빈값인지 확인해주는 것 , 빈값이면 badRequest나오게 test 163 | @NotEmpty 추가 못한다 164 | 사용하고 싶다면 직접 모듈 가져올것 165 | ``` 166 | 167 | > [백기선님 유튜브 설명](https://www.youtube.com/watch?v=cP8TwMV4LjE) 168 | 169 | 170 | * 스프링 security 사용해봤나요? 171 | -------------------------------------------------------------------------------- /file.txt: -------------------------------------------------------------------------------- 1 | 3-os 2 | this 키워드 3 | 자바에서 tcp udp 소켓 생성 방법 4 | 리틀엔디안 빅엔디안 5 | Reflection 6 | oop 5대 원칙 7 | 8 | 2-network 9 | iocp 10 | http keep alive / tcp keep alive 11 | ssl 12 | tcp udp 패킷구조 차이점 13 | 리피터, 허브, 브릿지, 라우터와 L2, L3, L4, L7 스위치 차이점 14 | 15 | -------------------------------------------------------------------------------- /file2: -------------------------------------------------------------------------------- 1 | * sass lass pass 2 | * Docker란 무엇인가요? 왜 사용하나요? 3 | * AWS를 사용해 본 경험이 있나요? 4 | * XML, json 차이 5 | * 최근 관심 있는 인터넷 세상의 이슈는 무엇인가요? 6 | * HTTP와 HTTP2의 차이 7 | * apache와 nginx차이 8 | 9 | 10 | -------------------------------------------------------------------------------- /make_title.sh: -------------------------------------------------------------------------------- 1 | #! /bin/bash 2 | 3 | ######################## 4 | ## 과목별로 실행 해준다 5 | ######################## 6 | 7 | function solution(){ 8 | 9 | # 1. 목록에 * 달아 주기 10 | i=0 11 | for list in "${lists[@]}"; do 12 | if [ $i -ne "0" ] 13 | then 14 | echo "* $list" 15 | fi 16 | i=$((i+1)) 17 | done 18 | 19 | echo " " 20 | # 2. * 제목 입니다(#제목-입니다) ; 형태로 만들기 21 | i=0 22 | answer="" 23 | for list in "${lists[@]}"; do 24 | # 공백 정확히 입력해야 if문 오류안난다 25 | if [ $i -ne "0" ] 26 | then 27 | # tr은 치환한것을 echo만 해줄뿐, 치환한것을 변수에 저장 못한다 28 | # 따라서 echo한것을 answer에 입력 29 | answer=$(echo "(#$list)" | tr ' ' '-') 30 | echo "* [$list]${answer}" 31 | fi 32 | i=$((i+1)) 33 | done 34 | 35 | echo "" 36 | 37 | # 3. ### & 태그 달아주기 38 | 39 | type=${lists[0]} 40 | 41 | tag="> :arrow_double_up:[Top](#${type}) 42 | :leftwards_arrow_with_hook:[Back](https://github.com/devham76/tech-interview-studyw#${type}) 43 | :information_source:[Home](https://github.com/devham76/tech-intervie-studyw#tech-interview)" 44 | 45 | 46 | i=0 47 | for list in "${lists[@]}"; do 48 | if [ $i -ne "0" ] 49 | then 50 | echo "## $list" 51 | echo $tag 52 | # echo -e $tag # 줄바꿈 필요하면 사용 53 | echo "" 54 | fi 55 | i=$((i+1)) 56 | done 57 | 58 | echo "" 59 | echo "-------------------------------------" 60 | echo "" 61 | } 62 | 63 | ######################## 64 | ## 1. 파일 돌면서 공백이 나오기 전까지 실행 65 | ######################## 66 | 67 | # 1. file.txt 파일에 있는 목록 읽기 68 | Lists=() 69 | i=0 70 | while read LINE; do 71 | # 해당 줄이 공백이 아니면 계속 읽는다 72 | if [ -z "$LINE" ]; 73 | then 74 | echo "빈값" 75 | solution $Lists[@] 76 | Lists=() 77 | i=0 78 | else 79 | # 공백 포함시, 따옴표 필수 80 | Lists[$i]="$LINE" 81 | echo "$Lists[0]" 82 | 83 | i=$((i+1)) 84 | fi 85 | 86 | done < file.txt 87 | -------------------------------------------------------------------------------- /result.txt: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/devham76/tech-interview-study/1bda06dff2a718bd00a174443fea8b2bf64030f7/result.txt --------------------------------------------------------------------------------