CHAPTER 2 동작 파라미터화 코드 전달하기

[kyupid]

다다음주 진행할 "챕터3 람다 표현식"이 분량이 꽤 많아 챕터2에 이어서 3.2까지 하도록하겠습니다.

CHAPTER 2 동작 파라미터화 코드 전달하기
2.1 변화하는 요구사항에 대응하기 @qkrtpgh5033
2.2 동작 파라미터화 @songinyong
2.3 복잡한 과정 간소화 @reddevilmidzy
2.4 실전 예제 @재이님
2.5 마치며

CHAPTER 3 람다 표현식
3.1 람다란 무엇인가? @kyupid
3.2 어디에, 어떻게 람다를 사용할까? @asas6978
3.3부터 다담주 진행

[kyupid]

람다 캡처링에 대해서 학습할 수 있었습니다. 람다 바디 내에서 지역 변수 사용할 때 제약 조건이 있었네요

[kyupid]

3.1 람다란 무엇인가? 에서 ..
Q) 람다 내에서 지역변수를 가져다가 마음대로 변경을 하게 되면 문제가 있다는데 왜 문제가 생기는지 잘 모르겠음. 납득이 안됨

public class Tester {

	ExecutorService executor = Executors.newFixedThreadPool(1);

	public void testMultiThreading() {
		// 스레드 A
		boolean doLoop = true;

		executor.execute(() -> {
			// 스레드 B
			while (doLoop) {
				// something to do
			}
		});
		doLoop = false;
	}
}

여기에서 doLoop 이 false로 변경되기때문에 컴파일에러가 발생한다. 즉 testMultiThreading() 에서 해당 지역변수를 변경하면 안되도록 강제하고 있다.
왜냐하면 람다는 별도의 스레드에서 실행되어질 수도 있기 때문이다.

만약에 doLoop 이 변경되는 코드가 있고(doLoop = false) 별도의 스레드(스택)에서 실행되어진다면,
람다에서는 doLoop 값이 true 인지 false 인지 다른 스택에 확인할 길이없다.

따라서 멀티 스레드 환경에서 문제가 생길 수 있기 때문에 외부 지역 변수의 값의 신뢰성 보장을 위해 이런 제약이 있다고 할 수 있다.

참고: https://madplay.github.io/post/effectively-final-in-java