지식 줍줍 🐿️

람다

설명

익명함수다. 익명함수 즉, 코드 블럭이다.
코드 블럭은 메소드 내에 존재해야 한다!

※ 익명함수

재사용 가능한 기능의 일부분을 전달하고 싶을때 사용하는것.
함수들에 함수를 인자로 전달하는 경우 (콜백?)

코드예시

//기본 문법 
(args) -> {
	//블라블라
}

/* 
ASIS: 람다는 타입 지시자(Integer)를 생략할 수 있다 

함수형 인터페이스가 타입을 설명하고 있어, 
컴파일러가 필요한 모든 정보를 제공해줄 수 있기 때문이다.
*/
(Intefer x) -> x + 1; 

// TOBE: 이렇게!
(x) -> x + 1 


//ASIS: 매개변수 하나인 인터페이스 메소드 을
(x) -> x + 1 

// TOBE: 이렇게 표현 가능
x -> x + 1

// ASIS: 익명클래스 일반적 사용
void annoymousClass() {
	final Server server = new HttpServer();
	waitFor(new Condition() {
		
		@Override
		public Boolean isSatisfied() {
			return !server.isRunning();
		}
	});
}

// TOBE: 람다 사용 - 클로저지만 람다다.
void Closure() {
	Server server = new HttpServer();
	waitFor(() -> !server.isRunning());
}	


// (별도) WaitFor 클래스 
class WaitFor {
	static void waitFor(Condition condition) throws
	InterruptedException {
		While (!condition.isSatisfied())
			Thread.sleep(250);
	}
}

public class LambdaStudy {
    private String firstName = "Jack";
    public void 람다가_firstName_에_직접_접근() {
        Function<String, String> addSurname = surname -> {
          
          // 람다가 firstName 변수에 직접 접근이 가능. (필드,메소드,지역변수에 접근 가능)
          return this.firstName + " " + surname; 
        };
    }
}

람다가 도입된 이유

설명

빅데이터를 다루기 위해 멀티코어를 활용한 분산처리, 즉 병렬화 기술이 필요 하였음.
그래서 java8 에서는 병렬화를 위해 배열, List, Set, Map을 강화하였고 스트림을 강화 하였다.
그리고 스트림을 효율적으로 사용하기 위해 함수형 프로그래밍, 함수형 프로그래밍을 위해 람다,
람다를 위해 인터페이스 변화가 수반 되었다.

빅데이터 지원 → 병렬화 강화 → 컬렉션 강화 → 스트림 강화 → 람다 도입 → 인터페이스 명세 변경 → 함수형 인터페이스 도입

람다의 장/단점

장점

코드가 간결하다. 개발자의 의도를 쉽게 파악할 수 있다.
병렬 처리에 유리함.
함수를 만드는 시간을 덜 들일 수 있다.

단점

코드 남용시 디버깅이 힘들 수 있다.
재귀 로직 만드는것은 어렵다.

메소드 참조

설명

메소드 참조를 람다로서 사용할 때엔 이미 존재하는 이름을 가진 메소드를 가리키는 것인데, 그것은 이미 몸체를 가지고 있다.
일반 메소드를 함수형 인터페이스로 전환하는 행동.

※ 함수형 인터페이스 (@FunctionalInterfate)

함수형 메소드 or SAM(단일 추상 메소드)
하나의 인터페이스에 하나의 메소드만 가질 수 있음.
부모의 함수형 메소드 오버라이드 가능

@FunctionalInterface
interface A {
	abstract void apply();
}

// 가능
interface B extends A {
	
	@Override
	abstract void apply();
} 

// 불가능
interface B extends A {
	
	@Override
	abstract void illegal();
} 

메소드 참조의 특징

쌍콜론(::)의 앞부분은 대상으로 하는 클래스명, 뒷부분은 메소드명
method 뒤에 소괄호()을 쓰지 않는다.

메소드 참조의 유형

생성자 참조 (String::new)
  쌍콜론 뒤에 new가 붙음
  String 클래스의 인자없는 생성자를 호출하는 람다를 생성
  () → new String() 과 같은 의미

정적 메소드 참조 (String::valueOf)
  x → String.valueOf(x)

두 가지 유형이 인스턴스 메소드 참조 (x::toString)
  x는 접근 가능한 특정 인스턴스라 가정
  () → x.toString()

람다의 예외 처리

설명

람다는 예외처리를 위한 새로운 문법이 존재하지 않음.
람다에서 던져진 예외들은 일반 메소드 호출과 동일하게 호출한 곳으로 전파 된다.
즉, 람다를 호출하는 메소드에서 어떻게 실행될지에 대해 책임을 지지 않음. 람다는 병렬 또는 미래의 어느 시점에 처리될 수도 있기 때문.
예외처리가 가능하도록 로직을 만들수는 있지만 코드가 장황해진다.

비지니스 로직 < 에러 처리 위한 보일러 플레이트 코드

함수와 클래스

설명

클래스는 인스턴스화가 되어야 함. 함수는 그렇지 않음.
클래스는 새로 생성되면 객체를 위해 메모리가 할당됨.
함수를 위한 메모리는 딱 한번 할당 됨. (자바 힙의 퍼머넌트(permanent)영역에 저장 됨.
객체는 자신만의 데이터를 가지지만 함수는 데이터와 연관 관계가 없다.
자바 클래스의 정적 메소드는 함수와 거의 유사하다.

참고

(책) 자바 람다 배우기
(책) 스프링 입문을 위한 자바 객체지향의 원리와 이해
https://coding-factory.tistory.com/265

프로세스

설명

실행중인 프로그램

※ 멀티 프로세스

다수의 데이터 저장 영역을 가짐 (다수의 T메모리를 가지는 구조)
프로세스 끼리 서로 참조 불가능 (공간 영역 자체가 분리)

스레드

설명

하나의 프로그램 내 여러개의 실행 흐름

※ 멀티 스레드
T메모리 모델(스태틱, 스택, 힙)의 스택 영역(메소드 영역)을 스레드 갯수 만큼 분할해서 사용하는 것.
서로 다른 스레드의 스택 영역은 접근 못하지만 스태틱영역, 힙 영역은 공유해서 사용하는 구조.
멀티 프로세스 대비 메모리를 적게 사용하는 구조.!!
전역 변수 사용시 문제가 될 가능성 존재 ((변수참조)락을 거는 방법이 있다고 함 (?))

스레드풀

스레드 풀은 작업처리에 사용되는 스레드를 제한된 개수만큼 정해놓고 작업큐 (Queue)에 들어오는 작업들을 하나씩 스레드가 맡아 처리.
정해진 큐에 들어온 작업을 하나씩 처리하기때문에, 요청이 늘어나도 전체 큐 갯수는 늘어나지 않기 때문에 성능이 급격히 저하되지 않음.

ExecutorService

ExecutorService는 스레드에서 비동기 적으로 작업을 실행할 수있는 인터페이스.
java.util.concurrent 패키지에 있고, 스레드 풀을 유지 관리하고 작업을 할당하는 데 도움이된다. 
또한 작업 수가 사용 가능한 스레드보다 많을 경우 사용 가능한 스레드가있을 때까지 작업을 대기열에 넣는 기능을 제공한다.

Fork Join Framework

병렬화 할 수 있는 작업을 재귀적으로 작은 작업으로 분할 후 서브태스크에 각각의 결과를 합쳐전체 결과를 만듬

Fork: 데이터 반복적으로 분리
Join: 서브 결과를 결합하여 최종 결과를 만듬

프로세스와 스레드의 차이

설명

프로세스는 메모리 영역을 공유하며, 스레드는 스택영역을 생성함

참고

https://wikibook.co.kr/java-oop-for-spring/ (책: 스프링 입문을 위한 자바 객체지향의 원리와 이해)
https://3dmpengines.tistory.com/2003

https://www.javatpoint.com/java-executorservice

https://cheershennah.tistory.com/170

https://www.geeksforgeeks.org/thread-pools-java/

https://black9p.github.io/2018/01/20/병렬-데이터-처리와-성능/

설명

여러 로직단에 적용되어야 할 특정 중복 로직을 여러 코드를 수정하지 않고 적용하는 것
흩어진 코드를 한곳으로 모으자!
횡단 관심에 따라 프로그래밍 하는것

※ 횡단
동서 방향으로 가로질러 가는것

※ 횡단 관심사 (Cross cutting concern)

다수의 모듈에 공통적으로 나타나는 부분이 존재
모듈별로 반복되어 중복해서 나타나는 부분반복과 중복은 분리하여 한곳에서 표현해야 한다라는것을 항상 인지해야 함.

특징

Aspect 으로 표현
로직(Code) 주입
로깅, 보안, 트랜잭션 기능이 반복적으로 나타남
AOP는 프록시 기반, 인터페이스 기반, 런타임 기반 이다.

메소드에 주입할 수 있는 영역

@Before: 대상 메소드 시작 전
@After: 대상 메소드 시작 후
    @AfterReturning: 대상 메소드 정상 종료 후 
    @AfterThrowing: 대상 메소드 예외 발생 → 종료 후

AOP 용어

Pointcut 지정자 관련

 
  execution
일치하는 메서드 실행 조인 포인트에 사용됩니다. 이것은 Spring AOP로 작업 할 때 사용하는 주요 포인트 컷 지정자입니다.

  within
특정 유형 내 결합 점에 대한 매칭을 제한합니다 (Spring AOP 사용시 매칭 유형 내에서 선언 된 메소드 실행).

  this
빈 참조 (Spring AOP 프록시)가 주어진 유형의 인스턴스 인 조인 포인트 (Spring AOP 사용시 메소드 실행)에 대한 매칭을 제한합니다.

  target
대상 객체 (프록시되는 애플리케이션 객체)가 주어진 유형의 인스턴스 인 조인 포인트 (Spring AOP 사용시 메서드 실행)에 대한 매칭을 제한합니다.

  args
인수가 주어진 유형의 인스턴스 인 조인 포인트 (Spring AOP 사용시 메서드 실행)에 대한 매칭을 제한합니다.

  @target
실행 객체의 클래스가 주어진 타입의 어노테이션을 가지고있는 join point (Spring AOP 사용시 메소드 실행)로 매칭을 제한합니다.

  @args
전달 된 실제 인수의 런타임 유형이 주어진 유형의 어노테이션을 갖는 결합 지점 (Spring AOP 사용시 메소드 실행)에 대한 일치를 제한합니다.

  @within
주어진 어노테이션 (Spring AOP를 사용할 때 주어진 어노테이션이있는 타입에서 선언 된 메소드의 실행)이있는 타입 내에서 조인 포인트에 대한 매칭을 제한합니다.

  @annotation
Join point의 주제 (Spring AOP에서 실행되는 메소드)가 주어진 어노테이션을 가지고있는 join point로 매칭을 제한합니다.

Pointcut 표현식 예제

 
  모든 공용 메소드 실행
execution(public * * (..))

  다음으로 시작하는 이름을 가진 모든 메소드의 실행 
setexecution(* set * (..))

  AccountService인터페이스에 의해 정의 된 모든 메소드의 실행 
execution(* com.xyz.service.AccountService. * (..))

  service패키지에 정의 된 모든 메소드 실행 
execution(* com.xyz.service. *. * (..))

  서비스 패키지 또는 하위 패키지 중 하나에 정의 된 모든 메서드 실행
execution(* com.xyz.service .. *. * (..))

  서비스 패키지 내의 모든 조인 포인트 (Spring AOP에서만 메서드 실행)
within(com.xyz.service. *)

 서비스 패키지 또는 하위 패키지 중 하나 내의 모든 조인 지점 (Spring AOP에서만 메서드 실행)
within(com.xyz.service .. *)

  프록시가 AccountService인터페이스를 구현하는 모든 조인 포인트 (Spring AOP에서만 메서드 실행) 
this(com.xyz.service.AccountService)

참고

https://wikibook.co.kr/java-oop-for-spring/ (책: 스프링 입문을 위한 자바 객체지향의 원리와 이해)
https://docs.spring.io/spring-framework/docs/current/reference/html/core.html#aop

• Blocking : 다음 순서를 기다림. 기다리는 동안 아무것도 못함.
• Non-blocking : 다음 순서를 기다리지 않고(결과받음) 그 다음을 실행.
• Synchronous : 요청에 대한 결과값을 요청한 주체가 인지함. (요청에 대한 결과 시간과 다음 요청시간이 동일).
• Asynchronous : 요청에 대한 결과값을 요청한 주체가 인지하지 않고, 결과를 주는 곳에서 따로 확인. 

- 참고

juneyr.dev/reactive-programming

프론트에서 보내지 않은 파라미터 값을 서버에서 받으려고 할때 발생.

@RequestParam의 required 여부 확인

ex. @RequestParam(value=“param”, required=false) MultipartFile param ....

로 정의하면 param 을 null로 받을 수 있다.

+ MultipartFile[]의 경우는 프론트에서 값을 안넘기더라도

기본 주소(null 이 아닌 기본 길이 0)가 존재하여 해당상황 발생 안함!

사용중인 포트 확인필요 -> 포트를 죽이세요.

• 참고
  https://brocess.tistory.com/290

Lombok플러그인을 설치 하였는지 확인하기!

(pom.xml으로 불러온다고 끝이 아니였다)

Help > Find Action > Plugins 검색 > Marketplace단에서 Lombok 검색하여 설치