diff --git "a/ETC/CI, CD\353\236\200.md" "b/ETC/CI, CD\353\236\200.md" new file mode 100644 index 0000000..1f556c6 --- /dev/null +++ "b/ETC/CI, CD\353\236\200.md" @@ -0,0 +1,62 @@ +# CI/CD란 + +## 요약 + +> 애플리케이션의 개발 단계를 자동화하여 짧은 주기로 고객에게 애플리케이션을 제공하는 방법 + +## CI/CD가 나온 배경 + +- 모든 개발이 끝난 이후에 코드 품질을 관리하는 고전적 방식의 단점을 해소하기위해 나타난 개념 +- 분업과 협업의 과정에서 코드의 Merge 과정은 까다롭고, 테스트하는데 큰 자원을 소비되게 된다. 이 문제를 해결하기 위해 도입 +- 개발 브랜치가 일정 기간 이상 이용되면, 통합의 어려움은 커지고 충돌 해결에 들어가는 시간이 길어지고 오류 발생 위험이 커진다.
이러한 단점을 극복하고자 변동 내용의 반영 빈도를 늘리는 **자동화**가 등장 + +## CI의 정의 + +- **지속적인 통합(Continuous Integration)** +- 어플리케이션의 **새로운 코드 변경 사항**이 정기적으로 **빌드 및 자동 테스트** 되어 공유 레포지토리에 **통합(병합)**하는 것 +- 개발자를 위한 자동화 프로세스(여러명의 개발자간의 코드 충돌을 방지하기 위한 목적) +- 자동화된 테스트에서 **동작을 확인**하고 변경으로 인해 문제가 생기는 부분이 발견되면 CI를 통해 빠르게 수정 가능 +- 버그를 신속히 찾아 해결하고 소프트웨어 품질 개선, 새로운 업데이트의 검증 및 릴리즈 시간 단축시키는 것이 핵심 목표 + +### CI를 만드는 데 필요한 4가지 규칙 + +- 모든 소스 코드가 있고 누구나 현재 소스(및 이전 버전)를 얻을 수 있는 단일 장소 유지할 것 +- 누구나 단일 명령을 사용하여 소스에서 시스템을 빌드할 수 있도록 빌드 프로세스를 자동화 할 것 + +- 단일 명령으로 언제든지 시스템에서 우수한 테스트 모음을 실행할 수 있도록 테스트 자동화할 것 +- 누구나 현재 실행 파일을 얻으면 지금까지 가장 완전한 실행 파일을 얻었다는 확신을 하게 할 것 + +> 이 중 가장 중요한 것이 **테스팅 자동화**!!
지속적인 통합을 하기 위해서는 무엇보다 이 프로젝트가 완전한 상태임을 보장하기 위해 테스트 코드가 구현되어 있어야만 한다. + +## CD의 정의 + +- **지속적인 서비스제공(Continuous Delivery)** or **지속적인 배포(Continuous Deployment)** + - **지속적인 서비스제공(Continuous Delivery)** + - 공유 레포지토리로 자동으로 Release 하는 것 + - 운영팀이 보다 빠르고 손쉽게 애플리케이션을 프로덕션으로 배포 가능 (**수동적 배포**) + - 프로덕션 환경으로 배포할 준비가 되어 있는 **코드베이스를 확보**하는 것이 목표 + - **지속적인 배포(Continuous Deployment)** + - 프로덱션 레벨까지 자동으로 deploy 하는 것 + - 애플리케이션을 프로덕션으로 릴리스하는 작업을 **자동화** + - 개발자가 애플리케이션에 변경 사항을 작성한 후 몇 분 이내에 애플리케이션을 **자동으로 실행**할 수 있는 것을 의미 +- 간단히 말하면 **배포 자동화 과정** +- 서버가 많을 경우 개발자가 일일이 배포를 진행하지 않아도 되므로, 리소스가 낭비되지 않는다. + +![CI/CD flow](https://www.redhat.com/cms/managed-files/styles/wysiwyg_full_width/s3/ci-cd-flow-desktop_edited_0.png?itok=TzgJwj6p) + +## CI/CD 종류 + +- Jenkins +- CircleCI +- TravisCI +- Github Actions + +등.. + +## 참고 + +- https://www.youtube.com/watch?v=0Emq5FypiMM&t=10s + +- https://www.redhat.com/ko/topics/devops/what-is-ci-cd +- https://devuna.tistory.com/56 +- https://www.martinfowler.com/articles/originalContinuousIntegration.html \ No newline at end of file diff --git "a/ETC/\355\217\255\355\217\254\354\210\230 \353\260\251\353\262\225\353\241\240\352\263\274 \354\225\240\354\236\220\354\235\274 \353\260\251\353\262\225\353\241\240.md" "b/ETC/\355\217\255\355\217\254\354\210\230 \353\260\251\353\262\225\353\241\240\352\263\274 \354\225\240\354\236\220\354\235\274 \353\260\251\353\262\225\353\241\240.md" new file mode 100644 index 0000000..2563272 --- /dev/null +++ "b/ETC/\355\217\255\355\217\254\354\210\230 \353\260\251\353\262\225\353\241\240\352\263\274 \354\225\240\354\236\220\354\235\274 \353\260\251\353\262\225\353\241\240.md" @@ -0,0 +1,150 @@ +# 폭포수 방법론과 애자일 방법론 + +## 소프트웨어 개발 방법론이란? + +소프트웨어를 개발하는데 있어 필요한 프로그래밍 개발 과정들을 정리하고 표준화하여 프로그래머들이 프로그래밍 개발과정에서 각 개인이 개발과정에서 일관성을 유지하여 프로젝트의 분야별 **프로그래머들간의 효과적인 협업**이 이루어 질 수 있도록 돕는 방법론을 말한다. + +소프트웨어 개발 방법론에서 가장 중요한 내용은 **프로그래머들간의 효과적인 협업**이라고 볼 수 있으며 대표적으로 **WaterFall 방법론, Agile 방법론**이 있다. + +## 1️⃣ 폭포수(Waterfall) 방법론이란? + +### 정의 + +- 마치 폭포수처럼 물이 위에서 아래로 흐르는 것을 빗대어 표현한 방법론 +- **각 단계별 순차적인 진행을 강조하는 방법론** +- 여러 단계가 병행적으로 진행되거나 **거꾸로 진행되는 경우는 거의 없다.** + +### 진행 과정 + +![폭포수_진행과정](https://upload.wikimedia.org/wikipedia/commons/thumb/e/e2/Waterfall_model.svg/1280px-Waterfall_model.svg.png) + +> 그림 출처 : 위키백과 + +``` +📌 요구사항 분석 → 설계 → 구현 → 검증(테스트) → 운영/유지보수 +``` + +- **요구사항 분석**
: 고객의 요구조건, 시스템 환경 등 사용자가 원하는 task 이해 및 타당성을 조사하고 SW 기능과 제약조건을 정의하는 명세서 작성하는 단계 + +- **설계**
: 요구사항 명세서를 바탕으로 이를 세분화함으로써 구현될 수 있는 형태로 전환 (S/W 전체 구조, 구조간 관계, 상세 알고리즘 등) + +- **구현**
: 설계단계에서 만들어진 설계서를 바탕으로 직접 코딩하여 S/W를 개발하는 단계 +- **검증(테스트)**
: 완성된 프로그램을 테스트하는 단계(통합테스트, 인수테스트, 시스템테스트 등) +- **운영/유지보수**
: 시스템의 사용 중 발생하는 여러 변경사항에 대해 적응하고 변화에 대비하는 과정 + +### 장점 + +``` +📌 사용 및 관리 용이, 이해하기 쉬움 +``` + +- 고전적인 방법론으로써 **적용 사례가 풍부**하다. +- 단계별로 진행되기 때문에 현재 단계에 대한 **이해가 빠르고 쉽다.** +- 각 진행 단계별 **문서를 작성**하기 때문에 진행 중 및 진행 이후에도 **전체 과정에 대한 이해와 관리가 쉽다.** +- 단계별로 정형화된 접근방식을 이용하기 때문에 **기술적인 위험요소가 적다.** +- 폭포수의 모든 단계에는 시작과 끝이 존재한다. 이해 관계자 및 고객과 진행 상황을 쉽게 공유할 수 있다. + +### 단점 + +``` +📌 하향식 접근, 피드백에 대한 빠른 대응 어려움 +``` + +- 전 단계의 작업이 모두 완료되어야 다음 진행이 가능하다. +- 요구사항을 완벽하게 작성해야 한다. + +- 고객요구 사항은 프로젝트가 진행됨에 따라 변경될 수 있는데, 이에 맞춰서 즉각적인 수정이 어렵고 큰 비용이 든다. +- 테스트 단계에 발견된 중요 결함에 대한 대응이 어렵다. + +### 언제 사용하면 좋을까? + +- 고객의 요구상이 단순하고 변경 가능성이 높지 않을 때 +- 프로젝트의 규모와 난이도가 높지 않을 때 +- 요구사항이 비교적 명확하게 정의되어 있을 때 + +## 2️⃣ 애자일(Agile) 방법론이란? + +### 배경 + +90년대 이후 트렌드가 급격하게 빨리 변화하는 시대가 되면서, 비즈니스 사이클(제품 수명)이 짧아지고 SW 개발의 불확실성이 높아지게 되었다. 개발의 불확실성이 높아짐에 따라, 전통적 방법론이 더이상 맞지 않다는 것을 느낀 사람들은 새로운 자신만의 SW 개발 방법을 구축해 사용하게 된다. + +즉, **경량 방법론 주의자**들은 일단 해보고 고쳐나가자는 방식으로 개발하게 되었다. 이런 경량 방법론 주의자들이 모여 자신들이 사용하는 개발 방법론을 공유하고, 공통점을 추려서 애자일이라는 용어에 의미가 담기게 된 것이다. + +> 경량 방법론 : 규칙이 적고 가볍게 대응을 잘하는 방법 + +그리고 2001년 경량 방법론 주의자 17명이 만나면서 서로 간에 추구하는 관점의 공통점을 추려서 '**애자일 SW 개발 선언문**'을 만들게 되었다. 이때부터 애자일이라는 용어에 의미가 담기게 되었다. + +> [애자일 소프트웨어 개발 선언](https://agilemanifesto.org/iso/ko/manifesto.html) + +### 정의 + +- 폭포수 방법론과 다르게 소프트웨어 개발 단계를 **명확하게 구분하지 않고 각 단계를 반복적으로 수행**하면서 진행 +- 이때 요구사항을 추가하거나 제외하면서 소프트웨어 개발 진행 +- 즉, **변화하는 상황에 맞게 유연하게 대응하는 방법론** +- 특히 애자일 방법론 종류는 현재 40여 가지가 넘지만 애자일 기업 중 73%가 **스크럼(Scrum) 방식**을 사용하고 있다. (ex. Spotify, Riot, Amazon 등) + +### 특징 + +- 절차와 도구보다 **개인과 소통을 중요**하게 생각한다. +- 문서화보다는 **소프트웨어가 잘 실행**되는데 가치를 둔다. +- 계획보다는 **효과적인 변경 대응에 중점**을 둔다. +- 고객과의 **피드백을 중요**하게 생각한다. + +### 스크럼(Scrum) + +![img](https://upload.wikimedia.org/wikipedia/commons/thumb/5/58/Scrum_process.svg/1920px-Scrum_process.svg.png) + +> 그림 출처 : 위키백과 + +- **제품 백로그(Product Backlog)**
: 개발할 제품에 대한 요구 사항 목록. 우선순위로 관리 +- **스프린트 백로그(Sprint Backlog)**
: 각각의 스프린트 목표에 도달하기 위해 필요한 작업 목록 +- **스프린트(Sprint)**
: 계획, 개발, 리뷰 작업 등 최소 단위의 반복적 개발 주기. 보통 1~4주 단위에서 선택 +- **일일 스크럼 회의(Daily Scrum Meeting)**
: 매일 15분 정도 진행되는 미팅 (어제 한일, 오늘 할일, 오류 등을 공유) +- **스프린트 회고(Sprint Retrospective)**
: 스프린트 마지막날 좋았던 점, 개선할 점 도출하고 더 나은 방향으로 개선 + +### 장점 + +``` +📌 협력, 빠른 피드백 반영 +``` + +- 스프린트마다 생산되는 실행 가능한 제품을 통해 **사용자와 의견을 나눌 수 있음** +- 회의를 통해 **팀원들간 신속한 협조와 조율**이 가능 +- 자신의 일정을 직접 발표함으로써 업무 집중 환경 조성 +- 프로젝트 진행 현황을 통해 신속하게 목표와 결과 추정이 가능하며 **변화 시도가 용이함** +- 개발하면서 지속적으로 테스트 되기 때문에 개발 초기에 해결 가능 + +### 단점 + +``` +📌 체계화된 문서가 적음 +``` + +- 추가 작업 시간이 필요하다. (스프린트마다 테스트 제품을 만들어야하기 때문) +- 빈번한 수정으로 개발시 인력들이 느끼는 피로도가 높다 +- 스크럼은 프로젝트 관리에 무게중심을 두기 때문에 프로세스 품질 평에는 미약하다. + +### 언제 사용하면 좋을까? + +- 잦은 요구사항 변경이 있을 때 +- 프로젝트의 규모가 커서 요구사항 분석 및 설계를 완벽하게 하기 어려울 때 + +## 📌 폭포수 vs 애자일 + +| | 폭포수 | 애자일 | +| ------------------- | --------------------------- | ----------------------------------------- | +| **요구사항** | 한 번에 정의 | 지속해서 반영 | +| 지향 | 계획 중심 | 학습 중심 | +| 수직/수평 | 수평적 단계별 개발 | 기능별 수직 개발 | +| **고객과 의사소통** | 적음 | 많음 | +| 진단방법 | 문서화된 진행 사항 진단 | 개발하고 있는 소프트웨어로 진행 사항 진단 | +| **통합/테스트** | 마지막 단계에서 통합/테스트 | 지속적인 통합/테스트 | +| 릴리즈 | 빅뱅 릴리즈 (자주하지 않음) | 빠른 릴리즈 | + +## 참고 + +- [폭포수_방법론](http://www.incodom.kr/%ED%8F%AD%ED%8F%AC%EC%88%98_%EB%B0%A9%EB%B2%95%EB%A1%A0) +- [폭모수 모델 VS 애자일 모델](https://universitytomorrow.com/19) +- [애자일이란?](https://gmlwjd9405.github.io/2018/05/26/what-is-agile.html) +- [애자일 스크럼 이해하기](https://medium.com/dtevangelist/scrum-dfc6523a3604) +- [폭포수와 애자일 주요 10가지 차이점](https://blog.naver.com/p1ngp1ng/120165638207) \ No newline at end of file diff --git "a/OS/\355\224\204\353\241\234\352\267\270\353\236\250 vs \355\224\204\353\241\234\354\204\270\354\212\244 vs \354\212\244\353\240\210\353\223\234.md" "b/OS/\355\224\204\353\241\234\352\267\270\353\236\250 vs \355\224\204\353\241\234\354\204\270\354\212\244 vs \354\212\244\353\240\210\353\223\234.md" new file mode 100644 index 0000000..e627822 --- /dev/null +++ "b/OS/\355\224\204\353\241\234\352\267\270\353\236\250 vs \355\224\204\353\241\234\354\204\270\354\212\244 vs \354\212\244\353\240\210\353\223\234.md" @@ -0,0 +1,156 @@ +# 프로그램, 프로세스, 스레드 + +> - 프로그램이란 특정 작업을 수행하기 위한 실행파일이다. 실행파일을 클릭했을 때 메모리 할당이 이루어지고, 이 메모리공간으로 코드가 올라간다. 이 순간부터 프로세스이다. +> - 프로세스는 OS로부터 자원을 할당받는 실행되고 있는 프로그램의 인스턴스이다. 각각 독립된 메모리 영역(Code, Data, Stack, Heap 구조) 등을 할당받는다. +> - 스레드는 프로세스의 가장 작은 실행단위로, 프로세스가 할당받은 자원을 이용한다. 프로세스 내에서 각각 stack과 PC 레지스터만 따로 할당받고 Code, Data, Heap 영역은 프로세스 내에 쓰레드끼리 공유하면서 실행된다. +> - 스레드를 사용하면 응답시간 단축, 빠른 통신과 비용적음, 빠른 문맥 교환, 시스템 처리량을 향상시킬 수 있지만, 스레드의 자원 공유는 동기화 문제에 신경을 써야하며 멀티스레드 프로그래밍은 구현과 디버깅이 어렵다는 문제점이 있다. + +## 프로그램(Programe)이란? + +- **특정 작업을 수행하기 위해** 작성된 일련의 지침을 포함하는 **실행 파일** + +- 컴퓨터의 주 메모리에 저장되지 않고, 디스크 또는 컴퓨터의 **보조 메모리에 저장**된다. + +- 프로그램은 주 메모리에서 읽고 커널에 의해 실행된다 + + ex) chrome.exe (웹 페이지 보기), notepad.exe (텍스트 파일 편집) + +- **특징** + - **수동적(정적) 개체(passive entity)**. 실행할 명령어 그룹을 저장.
당장 실행파일을 열어보면 다양한 명령어가 적혀있는 것을 알 수 있다. 이러한 명령어를 그룹으로 모아저 저장하는 것이 프로그램! + - 수동으로 **삭제할 때까지 메모리에 저장**된다. + - 프로그램은 **실행 없이 어떤 작업도 수행 불가능.** + +## 프로세스(Process)란? + +> program is in execution (실행 중인 프로그램) + +- 메모리에 올라와 **실행되고 있는 프로그램의 인스턴스(독립적인 개체)** + +- 프로그램이 실행되는 실행 단위 + +- 프로그램 실행 중에 생성되어 **주 메모리에 load**된다. + + ex) google 크롬 아이콘을 더블 클릭하면 크롬 프로그램을 실행하는 프로세스가 시작된다. + +- **특징** + + - **능동적(동적) 개체(active entity)**. 응용 프로그램의 목적을 수행함 + - **수명이 매우 제한적**. 작업이 완료되면 종료된다. + - 프로세스에는 OS로부터 **실행에 필요한 자원을 할당**받는다.
ex) 파일 디스크립터(file descriptors), 네트워크 포트, cpu시간, 메모리 영역(Code, Data, Stack, Heap 구조) + - 여러 프로세스가 동일한 프로그램과 관련될 수 있다.
ex) 메모장 프로그램의 여러 인스턴스 실행 가능 (각 인스턴스 = 프로세스) + - 프로세스에 대한 정보는 **PCB(Process Control Block)**에 저장된다. + +### PCB(Process Control Block) + +> 특정 프로세스에 대한 중요한 정보를 저장하고 있는 운영체제의 자료구조 + +- 사용자가 프로세스를 생성할 때마다 운영체제는 해당 프로세스에 해당하는 PCB를 생성한다. + +- **[PCB]에 저장되는 정보** + +| 이름 | 정의 | +| -------------------------------------- | ------------------------------------------------------------ | +| 프로세스 식별자 (Process-Id, PID) | 프로세스 식별 번호 | +| 프로세스 상태 (Process state) | new, ready, running, waiting, terminated 등의 상태를 저장 | +| 프로세스 우선순위 (Process Priority) | 수명, 소비한 자원 등으로 우선순위 나눔
숫자 값이 작을수록 해당 프로세스의 우선 순위 증가 | +| 회계정보 (Accounting Information) | 사용된 CPU 양과 시간, 시간 제한, 계정 번호 등 제공 | +| 프로그램 카운터 (Program Counter, PC) | 프로세스가 다음에 실행할 명령어의 주소 저장 | +| CPU 레지스터 (CPU Registers) | 인터럽트 발생 or 프로세스 간 문맥 교환 발생 시 임시 정보 저장. | +| PCB 포인터 (PCB Pointers) | 프로세스 상태가 ready인 다음 PCB 주소 저장 | +| 열린 파일 목록 (List of Open Files) | 프로그램이 실행되는 동안 필요한 모든 파일 정보 저장 | +| I/O 상태 정보 (I/O status Information) | 프로세스에 할당된 입출력 장치 목록 저장 | + +## 프로세스 상태 (Process State) + +![프로세스_상태도](https://github.com/KJY97/Note/blob/main/img/OS/%ED%94%84%EB%A1%9C%EC%84%B8%EC%8A%A4_%EC%83%81%ED%83%9C%EB%8F%84.png?raw=true) + +- **New** : 프로세스가 생성중인 상태 + +- **Running** : CPU를 잡고 명령어(instruction)를 수행중인 상태 +- **Ready** : CPU를 기다리는 상태 (다른 조건을 다 만족하고 CPU만 얻으면 되는 상태를 의미) +- **Blocked(wait, sleep)** : CPU를 주어도 당장 명령어(instruction)을 수행할 수 없는 상태 + - Process 자신이 요청한 event(예: I/O)가 즉시 만족되지 않아 이를 기다리는 상태 + - ex) 디스크에서 file을 읽어와야 하는 경우 +- **Terminated** : 수행(execution)이 끝난 상태 + +## 프로그램과 프로세스 차이점 + +| | 프로그램 | 프로세스 | +| --------- | ------------------------------------------------ | -------------------------------- | +| 정의 | 프로그래밍 목표를 달성하기 위해 정렬된 작업 그룹 | 실행 중인 프로그램 | +| 상주 위치 | 디스크 or 보조 메모리 | 주 메모리 | +| 개체 유형 | 정적, 수동적 개체(passive entity) | 동적, 능동적 개체(active entity) | +| 자원 관리 | 명령어 저장을 위한 메모리만 필요 | 리소스 요구사항이 매우 높음 | +| 수명 | 수명이 길다. (삭제 전까지 저장됨) | 수명이 짧고 매우 제한적 | + + + +## 스레드(Thread) + +> 프로세스 내의 실행 흐름 + +![스레드](https://i0.wp.com/javaconceptoftheday.com/wp-content/uploads/2014/11/ThreadsAndProcesses.png?w=1200) + +- 프로세스의 **실행 가능한 가장 작은 단위** + +- 프로세스는 동시에 실행되는 여러 스레드를 가질 수 있다. + + - 이러한 프로세스를 경량 프로세스(Lightweight Process) 라고도 부른다. + +- **분류** + + | User Threads | Kernal Threads | + | ----------------------- | --------------------- | + | 사용자에 의해 구현 | OS에 의해 구현 | + | 구현이 쉬움 | 구현 복잡 | + | 종속 스레드로 설계 | 독립 스레드로 설계 | + | 문맥 교환 시간이 짧음 | 문맥 교환 시간이 길다 | + | 하드웨어 지원 필요 없음 | 하드웨어 지원 필요 | + +### 멀티 스레딩 + +**하나의 프로세스를 다수의 실행 단위로 구분**하여 자원을 공유하고 자원의 생성과 관리의 중복성을 최소화하여 **수행 능력을 향상시키는 것** + +- 즉, 하나의 프로그램에 동시에 여러개의 일을 수행할수 있도록 해주는 것 +- 하나의 프로세스 내 **메모리와 자원을 공유**한다. +- 메모리의 **code, data, heap 영역은 공유**하고, **stack과 PC 레지스터는 따로 할당**받는다. + - **각 스레드는 독립적으로 수행**되어야 하기 때문. +- **장점** + - **응답시간 단축** : 여러 스레드로 분할되면 하나의 스레드가 실행을 완료될 때 즉시 출력 반환 가능 + - **빠른 통신** : 동일한 메모리 영역을 공유해서 여러 쓰레드 간 통신이 원활함 + - **빠른 문맥 교환** : 프로세스에 비해 캐시 메모리를 비울 필요가 없기 때문. + - **시스템 처리량 향상** : 각 스레드 기능을 하나의 작업으로 간주하면서 단위 시간당 완료되는 작업 수 증가함 +- **문제점** + - **동기화 문제** + - 공유하는 자원에 동시에 접근하는 경우, 프로세스와 달리 **데이터와 힙 영역**을 공유하기 때문에 어떤 쓰레드가 다른 쓰레드에서 사용중인 변수나 자료 구조에 접근하여 엉뚱한 값을 읽어오거나 수정할 수 있다. 따라서 동기화가 필요! + - 동기화를 통해 작업 처리 순서와 공유 자원에 대한 접근을 컨트롤할 수 있다. 그러나 불필요한 부분까지 동기화를 하면 과도한 lock으로 인해 병목 현상이 병목 현상이 발생해 성능 저하 가능성 높다. + - 구현이 어려움 + - 테스트, 디버깅하기 어려움 + - 하나의 스레드의 문제가 발생하면 전체 프로세스에 영향을 끼침 +- 사용 사례 + - 영상통신 : 영상을 받아 화면에 출력하는 작업과 영상을 생성하여 보여주는 작업이 동시에 발생 + - 웹 브라우저 : UI를 처리하는 작업과 표시할 데이터를 가져오는 작업이 동시에 발생 + - 게임 : 그래픽을 실행하는 작업과 UI를 그리는 서버통신을 담당하는 소켓 작업이 동시에 발생 + +## 프로세스와 스레드 차이점 + +| | 프로세스 | 스레드 | +| -------------- | ------------------ | -------------------------------------- | +| 정의 | 프로그램이 실행 중 | 프로세스의 세그먼트 | +| 프로세스 타입 | 중량 프로세스 | 경량 프로세스 | +| 종료 시간 | 많은 시간 소요 | 적은 시간 소요 | +| 생성 시간 | 많은 시간 소요 | 적은 시간 소요 | +| 문맥 교환 시간 | 많은 시간 소요 | 적은 시간 소요 | +| 메모리 공유 | 비공유 | 공유. 단, stack과 PC 레지스터는 비공유 | + + + +## Reference + +- https://javaconceptoftheday.com/differences-between-program-vs-process-vs-threads/ +- https://www.guru99.com/program-vs-process-difference.html#3 +- https://binaryterms.com/process-control-block-pcb.html +- https://www.geeksforgeeks.org/thread-in-operating-system/?ref=lbp +- https://www.guru99.com/difference-between-process-and-thread.html +- https://goodgid.github.io/What-is-Multi-Thread/ +