inner side

http://blog.naver.com/genesung?Redirect=Log&logNo=130043743373

http://www.javaservice.net/~java/bbs/read.cgi?b=discussion&c=r_p&m=qna&n=1053403354

"String의  + 연산이 컴파일러를 통해 new StringBuffer().append("xxxxxx"); 최적화 된다"란 전제하에

아래는 내가 공감하는 의견

"제 주장에서도 StringBuffer가 필요 없다는 것은 아닙니다. 이 차이도 이미 위에서 논의된
바가 있는데, + 하나만 놓고 보면 StringBuffer.append에 대해 아무 비효율이 없지만
+=이 등장하게 되면 문제는 완전히 달라집니다. 실제로 String을 StringBuffer로 바꾸어서
효과를 보았다는 사람은 아마 100% 이것 때문일 겁니다. +=은 대입이 있기 때문에 객체가 또
하나 생성될 수 밖에 없죠. 이건 안 보이는 임시 객체도 아니고 아예 프로그래머가 만든
임시 객체가 되는 겁니다. 이건 기본적으로 최대한 +=의 사용을 줄이고 +로 연결을 해가야
하지만 상황에 따라 loop를 돈다거나 조건이 복잡하게 들어간다면 피할 수 없는 경우도
많습니다. 바로 이런 경우에 StringBuffer를 써야하는 거죠."

"가독성에 대한 문제도 전 생각이 전혀 다릅니다. 가독성에 대해 느끼는 것은 물론 개인차가
있습니다만 이 문제가 중요한 것은 다른 사람도 자기가 쓴 코드를 읽어야하기 때문입니다.
따라서 일반적인 프로그래머들이 조금이라도 편하게 느끼는 쪽으로 코딩을 하는 게 바람직하겠죠.

가독성 뿐 아니라 코딩할 때 StringBuffer를 쓰면 훨씬 귀찮지 않습니까? 줄이 길어질수록
키보드를 몇십 번을 더 눌러야하고 하다못해 정규식으로 치환할 때도 몇 번을 더 눌러야합니다.
그렇게 해서 이득이 발생한다면 좋겠지만 아무 이득도 없는 일에 그런 일을 더 해준다는 건
비효율이란 비난을 피해갈 수 없는 거죠.

전 개인적으로 프로그래머는 충분히 게을러야한다고 생각합니다. 프로그래머를 귀찮게 만드는
코딩은 좋은 코딩이 아닐 확률이 높습니다. 프로젝트에서 단지 부지런하기만한 프로그래머만큼
악인 게 또 있을까요. "왜"라는 질문을 한 번만이라도 제대로 던져 보았다면 지금처럼
수많은 코드에 StringBuffer가 들어가지도 않을 꺼고 +=이 반복되지도 않을 겁니다.

synchronized 같은 것도 마찬가지죠. 이거 쓰면 프로그램 성능이 급격하게 떨어지는 
걸로 알고 있는 사람이 많죠. 그래서 이거 피해가려고 온갖 꽁수를 동원합니다. 그런데,
실제 알고보면 synchronized 안에 들어가는 코드가 수행속도가 아주 빨라서 별다른 
영향을 미치지 못하는 경우가 많죠.

제 얘기는 아, 퍼포먼스가 중요하지..하면서 무턱대고 StringBuffer를 쓰기 전에 딱 한 번만
자문해보자는 겁니다. 정말 이곳에 StringBuffer가 들어가야만 하는가? 하고 말입니다"

-그외 capacity를 적절하게 지정하는 StringBuffer vs 디폴트 StringBuffer의 경우-

디폴트 스트링 버퍼의 경우 append()결과에 따라 내부적으로 char[] 메모리를 확장시켜야

할 경우가 capacity를 설정한 스트링 버퍼보다 많은 것이다. 그 결과 참조가 끊긴 기존의

char[] 는 가비지 컬렉터의 처리대상으로 남게되고 이 갯수가 많아 질수록 gc의 부담이 클수

밖에 없다고 생각함.