# Process & Thread

프로세스와 스레드의 차이에 대해 설명해주세요.

* **프로세스**: 실행 중인 프로그램. 독립적인 메모리 공간 사용.
* **스레드**: 프로세스 내에서 실행되는 작업 단위. 같은 메모리 공간을 공유.



스레드들이 메모리를 공유하면 어떤 이점이 있고, 반대로 어떤 문제가 발생할 수 있을까요?

* **장점**: 통신 비용 없이 빠른 데이터 공유 가능.
* **단점**: 동시성 문제 발생 가능 (race condition, stale data 등)



그렇다면 스레드 간 동시성 문제를 해결하기 위한 대표적인 방법들에는 어떤 것들이 있고, 각각의 특징은 무엇인가요?

* **가시성**: `volatile` 사용 (main memory 보장)
* **원자성**:
  * `synchronized`
  * `ReentrantLock`
  * 불변 객체
  * CAS (Compare-And-Swap) – `AtomicInteger` 등



synchronized와 ReentrantLock은 모두 락을 사용해서 동시성을 제어하는데요. 두 가지의 차이점과 각각을 어떤 상황에서 사용하는 것이 적절한지 설명해주세요.

| 항목   | synchronized | ReentrantLock   |
| ---- | ------------ | --------------- |
| 타임아웃 | 불가능          | 가능 (`tryLock`)  |
| 인터럽트 | 불가능          | 가능              |
| 공정성  | 제어 불가        | `fair` 옵션       |
| 성능   | 비교적 낮음 (간단함) | 더 유연하고 고급 제어 가능 |



ReentrantLock의 `fair` 옵션은 어떤 역할을 하나요? 그리고 이 옵션을 true로 설정했을 때와 false일 때 각각 어떤 장단점이 있을까요?

* `fair = true`: FIFO 순서 보장 → 공정하지만 느림.
* `fair = false`: 성능 우선, 새로 온 스레드가 먼저 락을 획득할 수도 있음.



공정성(fairness)을 보장하는 락이 starvation을 완전히 해결해줄 수 있을까요? 만약 그렇지 않다면 어떤 상황에서 starvation이 여전히 발생할 수 있는지 설명해보세요.

* **공정성 모드**는 starvation을 **줄이지만 완전히 막지는 못함**.
* 예시:
  * CPU 시간이 편향되어 일부 스레드가 계속 락을 시도하지 못하는 경우.
  * `락을 획득할 기회`는 있으나, OS 스케줄링에 따라 실제 실행 기회가 부족할 수도 있음.
