알아가는 재미

배열은 같은 종류의 데이터들이 순차적으로 저장되는 자료구조 입니다.

메모리 시작주소를 기준으로 자료형의 크기 * 데이터 개수  만큼 메모리에 연속적으로 할당되어 있습니다.

만약 자료형의 크기가 1bit 라고 한다면

0x000000 DATA[0]

0x000001 DATA[1]

0x000002 DATA[2]

0x000003 DATA[3]

0x000004 DATA[4]

0x000005 DATA[5]

0x000006 DATA[6]

0x000007 DATA[7]

처럼 할당됩니다.

0x000000 DATA[0]

0x000001 DATA[1]

0x000002 DATA[2]

0x000003

0x000004 DATA[3]

0x000005 DATA[4]

0x000006 DATA[5]

0x000007 DATA[6]

처럼 할당되는 경우는 없습니다.

배열은 처음 할당된 크기에서 가변적으로 늘릴 수 없습니다.

동적배열이라는 자료구조가 존재하지만, 그것은 다른 자료구조이기 때문에 기본적으로 배열은 처음 크기를 정해서 생성하고,

그 이후에는 그 크기를 늘리거나 줄일 수 없습니다.

1. REST : HTTP 의 장점을 활용할 수 있도록 만든 아키텍처

2. REST API : REST 아키텍처에 맞게 설계한 API

3. RESTful API : API 가 REST의 제약을 잘 지킬수록 Restful 하다고 말합니다.

REST

REST (REpresentational State Transfer) 은, Roy Fielding 박사학위 논문에서 최초로 소개되었습니다.

HTTP 의 주요 저자 중 한 사람으로 그 당시에 HTTP 설계의 우수성에 비해 제대로 사용되어지지 못하는 모습에 장점을 최대한 활용할 수 있는 아키텍처로 REST 를 발표하였습니다.

REST 구성

ReSource

- 자원의 위치를 정의합니다.

- Client 는 URI 를 이용하여 자원에 접근할 주소를 최종 호출 단위까지 명확하게 특정합니다.

Verb

- 자원에 대한 행위를 정의합니다 (HTTP Method)

- Client 는 HTTP Method 를 이용하여 지정한 자원에 대한 조작을 요청합니다.

Representation

- 자원에 대한 행위의 내요을 정의합니다.

- Client가 Server에 자원에 대한 조작을 요청할 때, 조작에 필요한 데이터를 메시지로 표현하여 전송합니다.

HTTP Method ( REST API 에서 주로 사용되는 HTTP Method )

* 페이로드 : 여기서는 Message를 의미합니. 흔히, Body 에 Json Type 으로 Data 를 넘겨주는데 이같은 경우가 해당됩니다.

REST 데이터 포맷

흔히, 데이터를 JSON 형식으로 전송하고 JSON 형식으로 받기 때문에 JSON 만가능한 것으로 착각하는 경우가 있습니다.

그러나, JSON, HTML, XML, JavaScript, TEXT 등 다양한 포맷을 지원합니다.

앞선 글에서, GC 는 프로그램이 동적으로 할당했던 메모리 영역 중에서 필요없게 된 영역을 해제 하는 메모리 관리 기법 이라고 하였습니다.

또한 Java에서 GC 는 JVM 의 가비지컬렉터 가 동작한다고 하였는데요,

이번 글에서는 Java GC 에 대해서 조금 더 알아보려고 합니다.

* Heap영역 : 자바에서 객체를 생성하면 Heap 영역에 저장

Minor GC & Major GC

JVM 은 Heap영역을 설계할 때 2가지 전제조건으로 설계 되었습니다.

1. 대부분의 객체가 금방 접근 불가능한 상태가 된다.

2. 오래된 객체에서 새로운 객체로의 참조는 드물게 존재한다.

이는 대부분의 객체가 일회성인 경우가 많고, 메모리에 오래 남아있는 경우가 드물다는 것을 의미합니다.

이에 따라 Young영역 , Old 영역 으로 구분을 하여 설계하였습니다.

Young 영역 : 새로운 객체의 영역

- 새로운 객체는 이곳에 할당되며, 대부분의 객체가 일회성인 만큼 대부분의 객체는 Young 영역에 오래 남아있지 않고 사라집니다.

- Young 영역을 관리하는 GC 를 Minor GC 라고 합니다.

또한, Young 영역의 구조는 아래와 같이 이루어져 있습니다.

- Eden 영역 : 새로 생성된 객체가 할당되는 영역

Eden 영역이 가득찰때마다, MinorGC 실행

- Survivor1 영역 : Eden 영역에서 1번 이상 살아남은 경우 할당되는 영역

- Survivor2 영역 : Survivor1 영역이 가득찬 경우 Survivor1 영역에서 살아남는 객체가 할당되는 영역

Survivor2 영역에서 계속 해서 살아남으면, 해당영역의 객체들은 Old 영역으로 복사

Old 영역 : 오래된 객체의 영역

- 새로운 객체가 Young 영역에서 사라질 때, Minor GC 를 거쳤지만, 해제되지 않고 살아남은 객체들이 이곳으로 복사됩니다.

- Old 영역에서도 언젠가는 사라져야하는데 이러한 Old 영역을 관리하는 GC 를 Major GC 라고 합니다.

- Old 영역은 Young 영역보다 크며, MinorGC 에 비해 MajorGC는 10배 이상의 시간을 필요로 합니다.

- 이는 MajorGC 가 자주 호출된다면, 성능에 영향을 끼칩니다.

- 그에 따라 MajorGC 는 Old 영역의 메모리가 부족해질 때 호출됩니다.

Card Table 

위에서 오래된 객체에서 새로운 객체로의 참조는 드물게 존재한다고 하였습니다.

즉, 오래된 객체가 새로운 객체를 참조할 수도 있다. 라는 것을 의미합니다.

그렇다면,

Minor GC 는 Young 영역에서 해제되어야하는 대상을 찾아야할 때, Old 영역도 확인해야 겠네? 라는 결론이 나오게 됩니다.

하지만 문제가 하나 있습니다. Old 영역에 있는 객체가 Young 영역에 있는 객체를 참조하는 경우는 드물게 발생한다 에서

Old 영역중에 0개 or 1개 의 객체만 Young 영역의 객체를 참조할 수 있다는 것입니다.

n 개의 객체를 제거대상인지 식별하기 위하여 m개의 객체를 검사한다면 n*m 번의 검사가 실행됩니다.

이러한 문제를 해결하기 위하여 Card Table 이 등장합니다.

Card Table : Old 영역의 객체가 Young 영역의 객체를 참조하는 경우에 그에 대한 정보를 저장합니다.

- Minor GC 가 동작할때 Young 영역에 있는 객체들은 Old 영역에 있는 객체와의 n*m 번의 검사가 아니라,

Card Table 에 있는 객체를 확인하여 Young 영역의 객체중 GC 의 대상에서 벗어나야 하는 객체를 식별합니다.

기본적인 GC 공통 동작 : Stop The World & Mark And Sweep

MinorGC 와 MajorGC 는 세부적으로 동작방식이 다릅니다.

간단하게 MinorGC 에서는 CardTable 도 사용하는 로직도 필요하다는 것을 예로 들 수 있겠죠?

하지만 기본적으로 GC 가 실행될 때 공통적으로 동작하는 방식이 있습니다.

1. Stop The World

- JVM 의 가비지컬렉터가 GC 를 실행하기 위하여 GC 를 실행하는 쓰레드를 제외한 나머지 쓰레드를 모두 정지시킵니다.

GC 작업이 종료되면, 나머지 쓰레드를 다시 동작합니다.

즉, Stop The World란 JVM 이 GC 를 실행시키기 위하여 다른 쓰레드를 정지&재개하는 동작입니다.

2. Mark And Sweep

- GC 가 동작할 때, 사용되는 메모리와 사용도지 않는 메모리를 식별하는 Mark 작업과 사용도지 않는 메모리가 식별된 경우, 이를 해제하기 위한 Sweep 작업입니다.

요약

자바의 GC 는 MinorGC 와 MajorGC 로 나뉩니다.

MinorGC : Young 영역에 대한 GC, Young 영역의 구조중 Eden영역이 가득차면 실행됨. 실행속도가 빠르다.

MajorGC : Old 영역에 대한 GC, Old 영역이 가득차면 실행됨. 실행속도가 느리다.

* 객체의 잘못된 사용으로 GC 의 대상이 되지 못하여 메모리 누수가 일어나는 경우 Old영역에 할당되는 객체가 늘어나게 되고,

Old영역이 가득찰때마다 MajorGC 가 실행되는데, MajorGC 에서 해제되는 메모리가 적어지는 만큼 Old영역이 가득차는 경우가 빈번해집니다. 따라서 MajorGC 가 자주 호출되게 되고, 이는 곧 성능에 치명적으로 다가옵니다.

그 이후, Old영역이 가득 찾지만, 더이상 MajorGC 의 대상에 속하지 못하여 사용할 수 있는 메모리가 없어진 순간

펑~ 펑~ 펑 .....

메모리누수를 조심합시당 :)

GC란,

Java 를 경험한 사람들은 가비지컬렉션, 가비지컬렉션 하는 말들을 못들어봤을리가 없습니다.

그러나, Java 로 개발하는 사람들에게 가비지컬렉션이 뭔가요? 라는 질문을 하면 흠칫 하는 경우가 많습니다.

알고 있는데, 설명을 하지 못하는 것은 모른다고 보는게 맞습니다.

오늘은 이렇게 모르면 안되는, 하지만 모르는 경우가 많은

가비지 컬렉션(GC) 에 대하서 알아보려고 합니다.

GC (Garbage Collection) 란,

프로그램이 동적으로 할당했던 메모리 영역 중에서 필요없게 된 영역을 해제 하는 메모리 관리 기법입니다.

" 더이상 사용되지 않는 메모리를 제거합니다. "
" 참조되지 않는 메모리를 해제합니다."

" 자동으로 메모리를 관리해줍니다. "

와 같은 답변은 맞는듯 아닌듯 저 말만 듣고는 이해하기 쉽지 않습니다.

앞으로 GC 가 무엇인가요? 에 대한 답은 

프로그램이 동적으로 할당했던 메모리 영역 중에서 필요없게 된 영역을 해제 하는 메모리 관리 기법입니다.

로 했으면 합니다.

우리가 모르고 넘어가던 핵심포인트는 GC 는 메모리 관리 기법 중 하나 라는 것입니다.

GC 는 어쩌다 탄생했나?

기본적으로 C 와 C++ 등의 언어에서 사용되지 않는 메모리 영역을 해제하기 위해 수동으로 메모리를 관리하였습니다.

Lisp 라는 언어에서 이같은 수동 메모리 관리를 단순화하기 위하여 GC 가 발명되었습니다.

역사공부는 적당히 하고.... 결국

"수동 메모리 관리" -> "자동 메모리 관리" 를 하기 위해 탄생했다고 보면 됩니다.

GC 장단점

GC 를 기본적으로 제공하는 언어나, GC를 구현한 프로그램 에서는 다음과 같은 장단점이 존재합니다.

<장점>

아래와 같은 버그를 줄이거나, 방지할 수 있습니다.

1. 유효하지 않은 포인터 접근

- 이미 해제된 메모리에 접근하는 경우에 발생하는 버그입니다.

만약 메모리에 다른 값이 새로 할당되었다면, 해당 메모리를 바라보던 포인트는 전혀 다른 값을 반환하게 됩니다.

2. 이중 해제

- 이미 해제된 메모리를 다시 해제하는 경우에 발생하는 버그입니다.

ex) free() 같이 수동으로 메모리를 해제 하는 과정에서 이미 해제된 메모리를 한번더 해제 하면서 에러를 발생시킵니다.

3. 메모리 누수(메모리 릭)

- 프로그램이 더이상 필요로 하지 않는 메모리 영역이 해제되지 않고 남아있는 경우를 말합니다.

메모리 누수가 반복되는 경우 사용가능한 메모리 영역이 고갈나게되고, 그 경우 프로그램은 중단됩니다.

* 메모리 누수가 아님에도 메모리 영역이 고갈나는 경우는 GC 로도 막을 수 없습니다.

<단점>

1. 해제해야 하는 메모리를 결정하는 오버헤드

- GC 는 프로그램이 동적으로 할당했던 메모리 영역 중에서 필요없게 된 영역을 해제 하는 메모리 관리 기법입니다.

라고 하였습니다. 그렇다면 필요없게 된 영역을 누가 알려주죠? 개발자가 직접 알려주나요? 나 여기 필요없어.

그럴거면 수동으로 메모리를 관리하는 것과 무슨 차이가....

따라서, GC가 동작할 때, 필요없게 된 영역을 결정해야 하는 로직이 동작합니다.

이때 결정하기 위한 오버헤드가 발생합니다.

2. 할당된 메모리가 해제되는 시점을 알 수 없다.

- 일반적으로 GC 는 개발자가 호출하지 않습니다.(자바의 경우 JVM 의 가비지컬렉터 가 이를 실행합니다.) 즉, 개발자가 "변수=null" 을 통해서 더이상 사용하지 않기 위해 참조를 해제한다고 하더라도, GC가 동작하기 전까지는 메모리 영역에서 해제되지 않는다는 겁니다.

안드로이드를 기점으로 생각해볼까요? Activity 가 실행되고 있을 때, 해당 Activity 가 종료되면 Activity 가 사용하던 메모리 영역은 그 즉시 해제되나요? 확신할 수 있나요?

GC원리를 학습하면, 해제해야하는 대상을 결정하는 로직을 보게 됩니다. 그런 로직에 따라서 결정되는데 프로그램을 개발하는 순간에 GC 가 해제해야 하는 대상을 결정하는 로직과, GC가 일어나는 타이밍들을 100% 고려하여 작성할 수 있나요?

저희는 GC가 언제 동작하는지 예측하는것도 어려울 뿐더러, 그 GC 가 동작하는 순간에 어떤 메모리 영역을 해제해야 대상으로 선택했는지 에 대해서 알 수 없다고 봐야합니다.

< Java GC 에 대해서 좀 더 알아보고 싶다면 >

devhyeon0312.tistory.com/17 게시글을 확인해주세요 🤗

동시성 이슈는 결국 "공유자원" 으로 인해 발생한다고 보면 될 것 같습니다.

공유자원이란

그렇다면, "공유자원" 은 무엇일까요?

정말 단어 그대로 순수하게 자원을 공유한다고 보면 될 것같습니다.

서버와 클라이언트를 본다면, DB 의 데이터가 공유자원이 될수 있고,

프로세스 간에는 IPC 통신을 하면서 여러프로세스가 동일한 자원에 접근하는 경우에 해당 자원이 공유자원이 될 수 있고,

쓰레드간에는 여러쓰레드가 프로세스 힙메모리 등에 있는 자원에 접근하는 경우에 해당 자원이 공유자원이 될 수 있습니다.

단, 변하지 않는 Read Only 의 자원에 대해서는 동시성 이슈가 발생하지 않습니다.

그러나, 수정이 일어나는 자원에 대해서는 굉장히 조심해야 합니다.

실생활 예시

친구들과 팀프로젝트를 진행중입니다. 파일을 공유하기 위해 구글드라이브 사용하고 있네요.

팀장만 파일을 등록/삭제/수정 이 가능하다면, 팀원들이 받는 파일은 항상 팀장이 마지막으로 수정한 파일일 것입니다.

그러나 모두가 등록/삭제/수정 이 가능하다면?

0.팀원A와 팀원B가 파일을 각각 다운받았습니다.

1.팀원A가 파일에 1이라고 적혀있는 것을 0으로 고쳤습니다.

2.팀원B가 파일에 1이라고 적혀있는 것을 2로 고쳤습니다.

3.팀원A는 파일을 저장하였습니다.

4.팀원B도 파일을 저장하였습니다.

팀원A가 고친 값은 공중으로 사라지게 됩니다.

또다른 예를 볼까요?

0.팀원A와 B가 파일을 각각 다운받았습니다.

1. 팀원A는 발표횟수가 0이라고 되어있는 파일을 가지고 발표를 진행합니다.

2. 발표를 끝낸 팀원A는 발표횟수를 1로 올려두고 파일을 저장합니다.

3. 팀원B는 발표횟수가 0이라고 되어있는 파일을 가지고 발표를 진행합니다.

4. 발표를 끝낸 팀원B는 발표횟수를 1로 올려두고 파일을 저장합니다.

어라? 발표는 분명 2번 일어났는데, 최종적으로 발표는 1번만 한것이 됩니다.

Android Thread 에서 발생하는 동시성 이슈

Android 를 예시로 들겠습니다. 

안드로이드 프로젝트를 처음 동작시키면, UI Thread 와 Main Thread 가 존재합니다.

UI Thread 에서는 정말 UI만 그리는 작업을 진행합니다.

Main Thread 에서는 UI를 그리는데 필요한 데이터를 처리하는 작업을 진행합니다.

만약 Main Thread 에서 아직 처리되지 않아서 null 인데이터를 UI Thread 가 그리려고 하면 NullPointException 이 발생할 것입니다.

UI를 그리기 위해 필요한 Data 는 "공유자원" 에 해당합니다.

이처럼 당장 눈에 Thread 라는 것을 정의하지 않더라도, 자신이 사용하는 프레임워크라던가, 동작의 원리등에서 발생할 수 있는 "동시성 이슈" 는 항상 고민되어야 합니다.

Android API 동시성 이슈

간단한 API 를 단계별로 호출하고, 결과에 따라서 UI 를 update 하는 경우에는 크게 접하지 못했을 수도 있습니다.

그러나, 한 화면에 여러개의 API 가 호출되고, 여러개의 API 결과에 따라 UI 가 update 되는 경우에는 이런 문제가 발생할 수도 있습니다.

예를 하나 들어보겠습니다.

API 요청결과는 SUCCESS, FAIL 두가지로만 분류된다고 가정하겠습니다.

SUCCESS 인 경우에는 UI update 에 필요한 데이터가 null 인 경우는 없다고 가정하겠습니다.

또한 FAIL 의 경우에는 재시도 없이 FAIL UI 를 보여준다고 가정하겠습니다.

한개 API

1. API 요청 및 응답대기

2. SUCCESS : 필요한 데이터로 UI Update

2. FAIL : FAIL UI 표시

API 결과가 무엇이든, 동작에 문제는 없습니다.

여러 API

1. 첫번째 API 요청 및 응답대기

2. 두번째 API 요청 및 응답대기

3. 첫번째 API SUCCESS : 필요한 데이터로 UI Update // 두번째 API 결과로 얻는 Data 가 null 이라서 FatalError 발생

3. 첫번째 API FAIL : FAIL UI 표시

4. 두번째 API SUCCESS : FAIL UI 에서 SUCCESS UI 로 변경을 시도, // 첫번째 API 결과로 얻은 Data 가 null 이라서 FatalError 발생

5. 두번째 API FAIL : FAIL UI 표시

운좋게(?) 두개의 API 가 모두 FAIL 인 경우에는 FAIL UI 를 표시하면 되기 때문에 의도대로 동작한다고 볼수도 있습니다.

그러나, 한개의 API 라도 SUCCESS 가 일어나는 순간 저 로직은 FatalError 가 발생합니다.

해결과정을 알아볼까요?

Null 이 아닌 경우에만 해당 데이터가 사용되는 UI 를 그리라는 것입니다.

그러면 최소한 FatalError 에서는 벗어나겠지요?

그런데.. 저게 정말 맞는 해결방법일까요?

정답은. 때에 따라서 맞을수도, 틀릴수도 있다 입니다.

만약 정말 보이고자 하는 의도가 NULL 인 경우에 공백 등으로 UI 표시하는 것이 목적이라면, 저것은 맞다고 할 수 있습니다.

그러나, 의도된 UI or 다음 동작을 위해서 2개의 API 의 결과가 모두 필요한 경우라면, 저것은 틀리다고 할 수 있습니다.

만약 2개 API 의 결과가 필요하다면,  2개 API 의 반환된 결과에 따라서 처리로직이 구현되어야 합니다.

<첫번째 방법>

1. 첫번째 API 요청 및 응답대기

2. 첫번째 API SUCCESS 로 인해 대기

3. 두번째 API 요청 및 응답대기

4. 두번째 API SUCCESS 로 인해 UI Update

또는 첫번째 API FAIL or 두번째 API FAIL 의 경우에는 추가 요청없이 FAIL UI 표시

의 방법이 있겠네요. 이것은 여러 API 를 "순차적" 으로 사용하여 해결하는 방법입니다.

그러나, API 가 10개라면? 20개라면? 100개라면?

연관된 API 가 늘어날수록 위와같은 방법은 코드의 길이와 예외의 상황을 더이상 기억할수 없게 만들어버립니다.

<두번째 방법>

그럼 다음 방법을 살펴볼까요?

0. UI update 를 판단하는 쓰레드 동작

1. 첫번째 API 요청 및 응답대기

2. 두번째 API 요청 및 응답대기

3. 세번째 API 요청 및 응답대기

4. API 요청 결과가 모두 SUCCESS 인 경우 : 0번의 쓰레드의 SuccessCount = 3; 으로 UI Update

4. API 요청 결과가 부분 SUCCESS 인 경우 : 0번의 쓰레드의 SuccessCount < 3 && FailCount > 0 이므로 FAIL UI 표시

두번째 방법은 실제 사용시 Observer 를 사용한다거나, 편리하게 Rx를 사용한 API 콜을 처리하는 등으로 나아가게 됩니다.

이러한 과정은 결국 "동시성 이슈" 로 인해 나온 것이며, "왜" 필요한지 알게 되셨길 바랍니다.

프로그램(Program)

특정 작업을 하기 위해 일련의 명령어 모임

응용 소프트웨어(application software) & 어플리케이션(Application)

OS 위에서 동작하는 모든 소프트웨어

프로세스(Process)

프로세스란, 컴퓨터에서 연속적으로 실행되고 있는 컴퓨터 프로그램을 의미합니다.

또한, 메모리에 올라와서 실행되고 있는 프로그램의 인스턴스 라고 할 수 있습니다.

프로세스 메모리 영역 ( 코드, 데이터, 스택, 힙 )

프로세스 구조 ( 레지스터 + 메모리영역 )

프로세스 특징

각 프로세스는 독립적이며, 서로 다른 프로세스의 자원에 사용이 불가능하다.

만약, 서로 다른 프로세스의 자원을 사용하기 위해서는 프로세스간 통신을 구현해야한다. ( IPC 통신 )

만약 프로세스간 통신을 구현했을 때, 공유자원에 대한 동시성 이슈에 대해서도 고민해야 한다.

쓰레드(Thread)

쓰레드란, 프로세스 내에서 실행되는 흐름의 단위 를 의미합니다.

일반적으로 1개의 프로그램은 1개의 쓰레드를 가지고 있지만, 1개의 프로그램환경에 따라 여러개의 쓰레드를 가질 수 있습니다.

쓰레드 메모리 영역 ( 스택 )

쓰레드 구조 ( 레지스터 + 메모리영역)

쓰레드 특징

각 쓰레드는 속해있는 프로세스의 Code, Data, Heap 영역에 접근할 수 있다.

따라서, 하나의 쓰레드에서 프로세스 힙영역의 자원을 수정하면, 다른 쓰레드 변경된 자원의 결과를 알 수 있다.

이는 서로 다른 쓰레드가 같은 공유자원을 서로 다른 기준으로 변경했을 때, 동시성 이슈를 발생할 수 있다.

먼저,  동기와 비동기에 들어가기에 앞서 대체 헷갈릴 수 있는 단어들의 종류를 적고 시작하겠습니다.

동기 (Synchronity) : "같은시간"에는 1개의 작업만 처리할 수 있다.

비동기 (Asynchronous) : "같은시간"에 여러개의 작업을 처리할 수 있다.

동시성 (Concurrency) : 병렬과 병행을 모두 포함하여 사용됨. (모호함)

병렬성 (Concurrency) : A작업과 B작업이 "다른시간"에 번갈아가며 동작하며, "같은시간"에 실행되는 것처럼 보이게 할 수 있음.

병행성 (Parallelism) : A작업과 B작업이 "같은시간"에 같이 실행될 수 있음.

순차적 (Sequential) : 작업이 들어오면 해당 작업이 끝날 때 까지 다른 작업을 진행할 수 없음.

제가 "동기와 비동기" 로 블로그를 찾아보았을 때, 이런 정의를 본적이 있습니다.

해당 글의 내용을 전부 읽었을 때, 그 설명이 틀리지는 않았다는 것을 알 수 있었습니다.

근데 뭔가 느낌이 좋지 않았습니다. 왜???? 내용을 전부 읽지 않는다면, 저 표현은 엄청난 오해(의도와 정말 극단적으로 반대되는 해석) 를 살 수 있을 것 같기 때문입니다.

왜 오해를 사는지 살펴보겠습니다.

병렬(Concurrency) 은 A 작업과 B 작업이 실행되는 것이 동시(Concurrency) 에 일어나는 것처럼 보이지만, 실제로는 순차적으로 진행됩니다. (ex.멀티쓰레드)

병행(Parallelism) 은 A 작업과 B작업이 실행되는 것이 동시(Concurrency) 에 일어납니다. (ex. 멀티프로세스)

동시성(Concurrency)은 이러한 두 상황을 통틀어서 말하는 경우가 많습니다. 

자, 그럼 위에 정의로 가볼까요?

"동기(Synchronity)는 말 그대로 동시(Concurrency)에 일어난다는 뜻입니다."

- 동기는 마치 병행을 말하는 것 같네요. 포괄적으로 본다해도, 병렬을 말하는 것 같아요.

"비동기(Asynchronous)는 말 그대로 동시(Concurrency)에 일어나지 않는다를 의미합니다"

- 위에서 말한 동시가 병행을 말한것이라면, 이건 병렬을 말한거겠네요.  아니면, 위에서 말한 동시가 병행,병렬을 말한거면 이 친구는 그 어디에도 속할 수 없네요. 음.. 순차적 (Sequential) 이 된다는 것일까요?

어떤 해석이든 둘다 문제가 있습니다.

좌측은 동기(Synchronity) 의 진행과정을 표현했으며, 우측은 비동기(Asynchronous) 의 진행과정을 표현했습니다.

(빨,노,초 작업은 각각 필요한 데이터 수신을 의미한다고 하겠습니다.)

아~ 그럼 동기는 순차(Sequential) 이고, 비동기는 동시(Concurrency) 인가요?

아닙니다. 다른 그림을 또 볼까요?

좌측은 동기(Synchronity) 의 진행과정을 표현했으며, 우측은 비동기(Asynchronous) 의 진행과정을 표현했습니다.

(빨강은 UI 그리기, 노랑과 초록은 필요한 데이터 수신을 의미한다고 하겠습니다.)

정리하자면,

1. 동기(Synchronity) 는 작업중에 다른 작업이 들어오면 해당 작업을 멈추고, 다른 작업을 진행합니다. 다른 작업을 끝낸 후에 하지못한 작업을 마무리하죠. 즉, 동시간대에는 1개의 Task 만을 수행합니다.

ex. UI 를 그리는 작업을 하는 중에 데이터를 받아오는 작업을 진행하면, UI 그리는 작업을 중지하고, 데이터 받아오는 작업을 진행한 후에 UI 그리는 작업을 다시 진행합니다.

로딩화면(빙글빙글) -> 로딩화면정지(stop) -> 데이터수신

2. 비동기(Asynchronous) 는 작업중에 다른 작업이 들어오면 해당 작업을 멈추는 것이아니라, 동시(Concurrency)적으로 진행합니다.

멀티프로세스에서 비동기를 진행하면 병행이 될것이고, 단일프로세스에서 비동기를 진행하면 병렬로 처리할 것입니다. 즉, 동시간대에 여러개의 Task 를 수행합니다.

ex. UI를 그리는 작업을 하는 중에 데이터를 받아오는 작업을 시작하면, 동시(Concurrency)적으로 진행합니다.

로딩화면(빙글빙글)0.1초 -> 데이터수신0.1초 -> 로딩화면(빙글빙글)0.1초 -> 데이터수신0.1초 ->..데이터수신완료

이 표현이 왜 오해를 살 수 있는지 아실 것 같나요?

해당 표현은 마치, 동기의 작업방식을 비동기처럼 작성했고, 비동기의 작업방식을 순차적인것으로 오해할 수 있습니다.

실제 동작과 정말 극단적으로 반대되는 결과가 나올 수 있다는 거겠죠?

동기로 프로그래밍 했을 때 장점과 단점

<장점>

단일 Task 를 빠르게 처리할 수 있다.

<단점>

1. UI 를 그리는 작업중에 데이터수신이 발생하면 UI 가 멈춘것처럼 보이는 결과가 나오는데, GUI 프로그램에서는 치명적인 단점으로 다가온다.

2. 공유자원에 대한 문제가 발생한다.

비동기로 프로그래밍 했을 때 장점과 단점

<장점>

여러개의 Task 를 동시에 처리할 수 있다.

GUI 프로그래밍에서 UI 가 멈춘것처럼 보이는 결과를 방지한다.

<단점>

병행이 아니라, 병렬인 경우 각 Task 처리에 대한 속도가 느려진다.

역시 공유자원에 대한 문제가 발생한다.

+ 동기화(synchronization)

서로 다른 Task 가 공유자원을 사용하는 경우 하나의 자원의 일관성이 깨질 수 있습니다.

그에 따라 공유자원을 사용할 때는 일관성이 깨지지 않도록 해야합니다.

이러한 작업을 동기화 작업이라고 하며, 이 과정은 결코 쉽지 않습니다.

오늘의 결론

자신이 만들고자 하는 프로그램이 동기or비동기 중 어느 것으로 가야하는지 잘 생각하여 결정하고,

동기화처리를 해주어야 하는 공유자원이 있는지에 대해서도 신경을 써주어야합니다.

static 변수는 많은 단점이 있지만, 그 중 공유자원으로 사용되면서 이같은 문제를 발생시킬 수 있습니다.

static 변수가 아니더라도, 공유자원으로 사용되면서 이같은 문제를 발생시킬 수 있습니다.

1. HTTP란,

HTTP 는 W3상에서 정보를 주고받는 프로토콜이며, HyperText Transfer Protocol 의 약자입니다. 

*W3 : www(Word Wide Web) 로 인터넷에 연결된 컴퓨터를 통해 정보를 공유할 수 있는 전 세계적인 정보 공간

2. HTTP 특징

1. 일반적으로 TCP (Transmission Control Protocol) 를 사용한다.

2. 클라이언트와 서버 사이에 요청(Request) 과 응답(Response) 이 이루어진다.

3. 상태가없는(stateless) 프로토콜이다. (각 요청들은 서로 연관이 없다.)

4. 요청와 응답에서 주고받는 메시지는 평문으로 이루어져 있다.

5. 기본으로 80포트를 사용한다.

3. HTTP 상태코드

• 1xx (정보): 요청을 받았으며 프로세스를 계속한다
• 2xx (성공): 요청을 성공적으로 받았으며 인식했고 수용하였다
• 3xx (리다이렉션): 요청 완료를 위해 추가 작업 조치가 필요하다
• 4xx (클라이언트 오류): 요청의 문법이 잘못되었거나 요청을 처리할 수 없다
• 5xx (서버 오류): 서버가 명백히 유효한 요청에 대해 충족을 실패했다

4. HTTP 통신 과정

1. Server IP 가져오기 

2. Request & Response

5. HTTP 패킷의 구조 (Header 와 Body)

HTTP 패킷은 Header 와 Body 부분으로 나뉩니다.

Header : 보내고자하는 패킷에 대한 정보와 패킷이 도착해야 하는 곳에 대한 정보를 담아두고 있습니다.

• General header: 요청과 응답 모두에 적용되지만 바디에서 최종적으로 전송되는 데이터와는 관련이 없는 헤더.
• Request header: 페치될 리소스나 클라이언트 자체에 대한 자세한 정보를 포함하는 헤더.
• Response header: 위치 또는 서버 자체에 대한 정보(이름, 버전 등)와 같이 응답에 대한 부가적인 정보를 갖는 헤더.
• Entity header: 컨텐츠 길이나 MIME 타입과 같이 엔티티 바디에 대한 자세한 정보를 포함하는 헤더.

Body : 보내고자하는 내용이 담겨져있습니다.