학습목표
- 팀코칭 질문 답하기(개념 학습)
TIL
- 모니터락
- SOLID 원칙
모니터 락(monitor lock)
자바에서 모니터 락(monitor lock)은 동시성 제어를 위해 사용되는 특별한 유형의 락입니다. 자바에서 모든 객체는 기본적으로 내장된 락을 가지고 있으며, 이를 intrinsic lock 또는 monitor lock이라 부릅니다. 이것은 동시에 여러 스레드가 같은 객체에 액세스하려고 시도할 때 발생할 수 있는 데이터 경쟁 조건을 방지하는 데 사용됩니다.
모니터 락은 synchronized 키워드를 사용하여 획득할 수 있습니다. synchronized 키워드가 붙은 메서드를 호출하거나 synchronized 블록을 진입하려는 스레드는 해당 객체의 모니터 락을 획득해야 합니다. 이미 다른 스레드가 락을 획득한 경우, 락을 해제할 때까지 기다려야 합니다.
모니터 락의 획득과 해제는 자동으로 이루어지며, 일반적으로 개발자가 직접 관리할 필요는 없습니다. 하지만 이러한 자동 락 관리 덕분에 동기화 블록에서 예외가 발생하더라도, JVM(Java Virtual Machine)은 여전히 모니터 락을 정상적으로 해제합니다. 이렇게 되면 다른 스레드들이 락을 획득할 수 있게 됩니다.
불변객체도 모니터 락을 사용하는가? 기본적으로 다 있고 해서.... 이건 자바의 기본 기능인가?? 그러면 왜 쓰래드 안전이 보장되지 않는 상황은 왜 존재하는 거지? 모니터락을 이용하지 않아서 인가?
불변 객체(immutable object)는 상태가 변하지 않는 객체를 말합니다. 즉, 한 번 생성되면 그 상태를 변경할 수 없는 객체입니다. 불변 객체는 자연스럽게 스레드에 안전(thread-safe)합니다. 왜냐하면 여러 스레드가 동시에 이 객체를 접근하더라도 객체의 상태가 변하지 않기 때문입니다. 그러므로 불변 객체에서는 일반적으로 모니터 락이 필요하지 않습니다.
모니터 락은 자바의 기본 기능 중 하나입니다. 모든 자바 객체는 내장된 락을 가지고 있습니다. 그러나 이것이 모든 상황에서 스레드 안전성을 보장하는 것은 아닙니다.
모니터 락을 사용하면 한 번에 하나의 스레드만 특정 코드 블록을 실행할 수 있게 함으로써 데이터 경쟁 상황을 방지할 수 있습니다. 하지만 모니터 락은 기본적으로 메서드 또는 블록 수준에서만 작동합니다. 이렇게 되면 다수의 메서드나 블록을 걸쳐 원자성(atomicity)이 보장되어야 하는 연산에 대해 모니터 락만으로는 충분하지 않을 수 있습니다.
예를 들어, 연산 A와 연산 B가 모두 `synchronized` 메서드라고 하더라도, 스레드1이 연산 A를 수행한 직후 스레드2가 연산 B를 수행할 수 있는 시간창이 존재합니다. 이런 경우 데이터의 일관성이 깨질 수 있습니다.
따라서 여러 메서드나 블록을 걸쳐 데이터 일관성을 유지해야 하는 경우, 추가적인 동기화 전략이 필요할 수 있습니다. 이를 위해 synchronized블록, java.util.concurrent 패키지의 도구, 락 객체 등이 사용될 수 있습니다.
모니터 락은 쓰래드 안전을 보장하기 위해 사용하는 방법 중 하나인건가?? 개발자가 따로 관리 할 필요가 없다고 하는데 JVM의 어떻게 모니터락을 실행하고 해제할 판단 기준은 뭐지?? 어딘가에 관련 코드가 있는가?
네, 모니터 락은 자바에서 제공하는 쓰레드 안전성(thread safety)을 보장하기 위한 동기화 기법 중 하나입니다.
모니터 락은 자바에서 `synchronized` 키워드를 사용할 때 자동으로 획득 및 해제됩니다. JVM(Java Virtual Machine)은 이 키워드를 보고 언제 락을 획득하고 해제할지 판단합니다.
예를 들어, 아래의 코드를 봅시다:
public synchronized void myMethod() {
// some code
}
이 경우, 어떤 스레드가 `myMethod()`를 호출하려 할 때, 해당 스레드는 먼저 객체의 모니터 락을 획득해야 합니다. 이 락은 메서드가 종료될 때 자동으로 해제됩니다.
동일한 개념은 `synchronized` 블록에도 적용됩니다:
public void myMethod() {
synchronized(this) {
// some code
}
}
위 코드에서 `synchronized(this)` 블록은 `this` 객체의 모니터 락을 획득하려 시도하며, 블록이 종료될 때 락이 자동으로 해제됩니다.
이러한 과정들은 JVM이 자동으로 처리하므로, 개발자가 직접 락을 관리할 필요는 없습니다. 그러나 동시성 제어는 복잡한 주제이기 때문에, `synchronized` 키워드의 사용, 적절한 락 구조, 그리고 데드락(두 개 이상의 프로세스나 스레드가 서로 상대방의 작업이 끝나기만을 기다리며 결과적으로 아무것도 완료되지 못하는 상태)을 피하는 등에 대해 잘 이해하고 있어야 합니다.
synchronized 라는 키워드를 내가 몰랐네 이 키워드는 뭐고 어떤 기능을 하는 거고 어떨 때 쓰는 거야??
`Synchronized`는 자바에서 동기화를 구현하는데 사용되는 키워드입니다. 이 키워드는 여러 스레드가 동시에 같은 객체의 상태를 변경하는 것을 방지하는데 사용됩니다. `Synchronized` 키워드는 메서드나 블록에 적용될 수 있으며, 해당 부분의 코드는 한 번에 하나의 스레드만 실행할 수 있습니다.
1. `Synchronized` 메서드: `Synchronized` 키워드가 메서드 선언에 사용되면, 해당 메서드는 한 번에 하나의 스레드만 실행할 수 있습니다. 아래는 사용 예시입니다.
public synchronized void syncMethod() {
// code to be synchronized
}
위 코드에서 `syncMethod()` 메서드는 `synchronized` 키워드로 인해 한 번에 하나의 스레드만 접근할 수 있습니다. 만약 한 스레드가 이 메서드를 실행 중이라면, 다른 스레드들은 메서드가 종료되어 락이 해제될 때까지 기다려야 합니다.
2. `Synchronized` 블록: 특정 코드 블록에 `synchronized` 키워드를 사용하면 해당 코드 블록은 한 번에 하나의 스레드만 실행할 수 있습니다.
public void someMethod() {
synchronized(this) {
// code to be synchronized
}
}
위의 코드에서 `synchronized(this)` 블록 내부의 코드는 한 번에 하나의 스레드만 실행할 수 있습니다. 이 경우 락은 `this` 객체에 걸립니다. 만약 다른 스레드가 같은 객체의 `synchronized` 블록이나 메서드를 실행하려고 한다면, 락이 해제될 때까지 기다려야 합니다.
`Synchronized`는 여러 스레드가 동시에 데이터를 변경하는 것을 방지하므로, 동시성 문제를 해결하는 데 도움이 됩니다. 그러나 잘못 사용하면 성능 저하를 일으키거나 데드락을 유발할 수 있으므로 주의해야 합니다.
자바에서 SOLID 원칙이라는 것이 있어??
네, 좀 더 상세히 SOLID 원칙들에 대해 설명하겠습니다.
- Single Responsibility Principle (SRP): 이 원칙은 각각의 클래스나 모듈이 하나의 책임만을 가져야 한다는 것을 의미합니다. '책임'은 변경의 이유를 의미하며, 클래스가 여러 책임을 가지고 있다면 그것은 클래스가 여러 변경의 이유를 가지고 있음을 뜻합니다. 이 원칙을 따르면 수정이 필요할 때 관련된 클래스만 수정하면 되므로 유지 보수가 쉬워집니다.
- Open-Closed Principle (OCP): 이 원칙은 소프트웨어의 구성요소(클래스, 모듈, 함수 등)가 확장에는 열려 있고 변경에는 닫혀 있어야 한다는 것을 의미합니다. 즉, 기존 코드를 변경하지 않고도 새로운 기능을 추가할 수 있어야 한다는 것입니다. 이를 통해 기존 코드의 안정성을 유지하면서도 시스템을 확장하는 유연성을 가질 수 있습니다.
- Liskov Substitution Principle (LSP): 이 원칙은 하위 타입은 상위 타입의 객체를 완벽하게 대체할 수 있어야 한다는 것을 의미합니다. 다시 말해, 부모 클래스의 인스턴스를 자식 클래스의 인스턴스로 바꿔도 프로그램의 동작에 문제가 없어야 합니다.
- Interface Segregation Principle (ISP): 이 원칙은 클라이언트가 사용하지 않는 인터페이스에 의존하게 해서는 안 된다는 것을 의미합니다. 즉, 한 클래스는 자신이 사용하지 않는 인터페이스를 구현하는 데 강요받지 않아야 합니다. 이를 통해 불필요한 종속성을 최소화하고 유지 관리성을 향상시킬 수 있습니다.
- Dependency Inversion Principle (DIP): 이 원칙은 상위 수준의 모듈이 하위 수준의 모듈에 의존하지 않고, 모두가 추상화에 의존해야 한다는 것을 의미합니다. 이를 통해 구성 요소 간의 느슨한 결합을 유지하고, 시스템의 변경이나 확장을 더 유연하게 할 수 있습니다.
이 원칙들은 소프트웨어 개발에서 좋은 구조를 설계하고 문제를 효과적으로 해결하는 데 도움을 줍니다. 하지만 이러한 원칙들은 지침일 뿐, 모든 상황에 항상 적용해야 하는 규칙은 아닙니다. 상황에 따라 원칙을 유연하게 적용하는 것이 중요합니다.
객체지향 프로그래밍의 단점은 있을까? 있으면 무엇일까?
객체지향 프로그래밍(Object-Oriented Programming, OOP)은 많은 장점을 가지고 있지만, 어떤 상황이냐에 따라 몇 가지 단점을 가질 수 있습니다. 다음은 객체지향 프로그래밍의 몇 가지 일반적인 단점입니다:
1. 복잡성: 객체지향 프로그래밍은 클래스, 객체, 상속, 다형성 등 다양한 개념을 도입합니다. 이러한 복잡성 때문에 초보 개발자들이 객체지향 프로그래밍을 배우고 이해하는 것이 어려울 수 있습니다.
2. 설계 난이도: 객체지향 프로그래밍은 어플리케이션을 더 유연하고 확장 가능하게 만들지만, 이를 위해서는 더욱 복잡하고 고려해야 할 사항이 많은 설계가 필요합니다. 잘못된 설계는 유지보수가 어려운 코드를 만들 수 있습니다.
3. 처리 속도: 일반적으로 객체지향 프로그램은 같은 기능을 수행하는 절차 지향 프로그램보다 처리 속도가 느릴 수 있습니다. 이는 객체 생성, 메서드 호출 등 추가적인 오버헤드 때문입니다.
4. 메모리 사용: 객체지향 프로그래밍에서는 객체를 많이 사용하게 됩니다. 각 객체는 메모리를 차지하며, 이로 인해 메모리 사용이 증가할 수 있습니다.
5. 비객체지향적 요소와의 상호작용: 기존의 절차 지향적인 시스템이나, 객체 지향이 아닌 시스템과의 상호작용이 필요한 경우에는 추가적인 변환 작업이 필요할 수 있습니다.
객체지향 프로그래밍은 매우 강력한 패러다임이지만, 사용 사례와 요구 사항에 따라 적절한 도구를 선택하는 것이 중요합니다. 일부 문제는 절차적, 함수형, 또는 선언형 접근법이 더 효과적일 수 있습니다.
함수형 프로그래밍은 왜 병렬성이 좋나요?
함수형 프로그래밍은 주로 함수의 평가에 초점을 맞추며, 불변성과 부작용이 없는 프로그래밍을 강조합니다. 이러한 특성은 병렬 처리와 매우 잘 맞습니다. 병렬 프로그래밍에서는 여러 작업이 동시에 실행되므로, 작업 간에 데이터를 공유하거나 변경하지 않는 것이 중요합니다.
다음은 함수형 프로그래밍이 병렬성을 쉽게 만드는 몇 가지 이유입니다:
1. 불변성: 함수형 프로그래밍에서는 데이터가 한번 생성되면 그 상태가 변하지 않습니다. 이러한 불변성은 동시에 여러 스레드에서 작업을 수행할 때 동기화 문제를 피할 수 있게 해줍니다. 한 스레드가 데이터를 변경하면 다른 스레드에서 이 데이터를 사용할 때 문제가 발생할 수 있습니다. 그러나 데이터가 불변하다면 이러한 문제가 발생하지 않습니다.
2. 부작용 없음: 함수형 프로그래밍에서 함수는 주어진 입력에 대해서만 결과를 반환하고 외부 세계에 영향을 미치지 않습니다. 이것은 함수의 순수성을 의미하며, 이러한 순수한 함수는 언제, 어디서, 어떤 순서로 평가되든 항상 같은 결과를 반환합니다. 이러한 특성은 함수의 동시 실행을 안전하게 만들어 줍니다.
3. 고차 함수와 람다 함수: 고차 함수는 다른 함수를 인자로 받거나 결과로 반환하는 함수입니다. 람다 함수(또는 익명 함수)는 이름 없이 정의되고 사용될 수 있는 함수입니다. 이런 함수들은 데이터의 리스트에 대해 동작을 적용하거나 병렬로 처리할 작업을 쉽게 만들어줍니다.
따라서, 함수형 프로그래밍 패러다임은 동시성과 병렬성에 있어 큰 이점을 제공하며, 멀티 코어 및 병렬 컴퓨팅이 중요해진 현재의 컴퓨팅 환경에서 매우 유용합니다.
'[F-Lab 66해빗 페이백 챌린지 ]' 카테고리의 다른 글
| [F-Lab 모각코 페이백 19일차] 팀코칭 질문 정리(인터뷰 준비, 개념 학습) (0) | 2023.06.02 |
|---|---|
| [F-Lab 모각코 페이백 18일차] 팀코칭 질문 (인터뷰 준비 및 개념 학습), MVVM 패턴, MVP 패턴 (0) | 2023.06.01 |
| [F-Lab 모각코 페이백 16일차] 팀코칭 질문 정리 (인터뷰 준비, 개념 학습) (0) | 2023.05.30 |
| [F-Lab 모각코 페이백 15일차] JSP, 서블릿(Servlet), Request 기본 객체 (0) | 2023.05.29 |
| [F-Lab 모각코 페이백 14일차] JSP, Encoding, UTF-8, Character Set (0) | 2023.05.28 |