programming : 사용하지 않는 변수를 계속 살려두지 마세요.. 동정심 따윈...

※ 객체와 객체가 가지고 있는 인스턴스 변수 및 메소드 내의 로컬 변수들에 대해 오해를 좀 했네요.
    블록과 메소드를 이용하여 변수들의 삶을 명시해주는 것은 메모리 입장에서는 상관이 없습니다.
    그저 linking이 있느냐 없느냐의 차이이지, 객체는 어쨌든 변수들을 모두 가지고 메모리에 상주하며
    gc는 객체를 참조하고 있는 변수가 있는지 여부만 확인하고 객체를 가지고 갑니다.
    따라서, 객체안에서 선언되었던 모든 변수들은 객체의 라이프사이클과 함께한다고 보면 되겠습니다.

과거에 작성된 여러 jsp source code들을 접하면서 느끼는 점은
대체 왜이렇게 엉망인가하는 당혹감입니다.
(아무래도 java파일보다는 jsp파일 작성시 이런 경우가 많더군요)

물론 그 당시에 어떠한 패턴이 정의되어 있지 않았었기에 생길 수 있는 문제점이려니 하고
넘어가려하지만 이러한 소스들을 접할때마다 느끼는 당혹감은 어쩔 수가 없네요;;

소스 중간중간에 선언되어있는 수많은 인스턴스변수들.
대체 어떻게 관리하려고 이렇게 해놨나 싶습니다;;;

생성된 객체들은 이러한 변수들을 들고 메모리에 올라가며
링킹이 없는 객체들은 차곡차곡 가비지컬렉터 메모리에 쌓이죠.
가비지컬렉터에서 올드메모리인가 하는 메모리가 있는데 차곡차곡 쌓인 메모리들은
나중에 한꺼번에 제거됩니다.
즉, 링킹이 없어진 객체들은 그때그때 삭제되는 것이 아니라 한꺼번에 삭제된다는거죠.

그래서 객체는 최대한 가벼운게 좋습니다. 가비지컬렉터에 의해 채워진 메모리가
자주 비워지는 것만큼 부담되는 일은 없기 때문이죠.

따라서 jsp나 java나 마찬가지로 변수를 선언하고 사용할 때에는 반드시 scope를 명확히 해주는 것이 좋습니다.
변수의 삶은 개발자가 정해줄 수 있죠.
scope를 명확히하는 것은 단순히 block으로 변수의 라이프사이클을 명시해주는 방법도 있겠고
아니면 메소드로 그 일련의 작업을 마련해주는 방법도 있겠습니다.

이러한 변수의 라이프사이클을 명시해주는 이유는 퍼포먼스 때문이라고 작성하였었으나,
서버나 디바이스의 퍼포먼스 때문은 아니고.

작성된 java, jsp를 관리. 즉, 유지보수를 위한 것입니다.
여기저기 선언되어 있는 변수들로 인하여
유지보수가 얼마나 힘든지는 겪어본다면....느끼실 것입니다.