그러게요 이런시도를 해보진 않아서 몰랐는데 일부러 다른 객체 null로 초기화한 상태에서

String과 참조변수를 더하니 null이 문자열로 변환되서 더해지네요.

초기화 하는건 맞습니다. String도 클래스니까. 다만 객체가 null로 초기화 되었을 때 "null" 이라는 문자를 출력하네요.

그냥 JVM 이 그런갑다 해야될거 같네요 ㅎㅎ

변수형에 따라서 자동으로 준비[?]해놓는다던지..ㅋㅋ;;;

str=null10은 좀 이해가 안되는 부분이군요... 참;;;

null도 예약어 맞죠? 전 항상 NULL로 써서...

NULL과 null를 구분하긴 하지만,

물리주소도 할당 안되어 있는데, 후에 +연산자를 문자열 붙이기로 알아듣는다면

자료형이 str이니 따옴표도 안붙였는데 jvm마음대로 값을 넣은듯 넣지않은듯 가지고 있다가

후에 문자열이 추가되면 추가했다는 결과인데... 뭔가 심히 이상하네요. 시키지도 않은일을 하다니 ㅡㅡ;

String str =""; 로 초기화 하시면 [""+문자열 끝을 나타내는 데이터] 로 들어가니 당연히 "10"이 출력되어야 하겠죠...

뭔가 확실히 이상합니다 +_+

ㅎㅎ 댓글보면서 배워가내요 ㅋ 이제 소켓프로그램 배우는대 언재 다할지;;; ㅠㅠ(머 끝이 있진안치만요 ㅎㅎ)

우왕~~ 전문가님들 ㄷㄷㄷㄷㄷㄷ

null이 뭐에욤??

쩝. 전문분야가 아니라서 안 쓰려다가 요즘 java관련 사이트에 도움을 주고 있어서 조금 적어봅니다.

일단 Java에서 null은 예약어임과 동시에 JVM의 캐쉬내에 항상 존재하는 오브젝트입니다.

System.out.print( (Object)null );

과 같은 식으로 null이 오브젝트라는 것을 확인할 수 있습니다.

이 null 은 특히 여러 오브제트에서 중요하지만 문자계열에서 특히 더 중요합니다.
특히나 가장 많이 쓰고 가장 흔하게 사용하는 String 클래스에서 좀 중요합니다.

예를 들어보면

for( int index = 0 ; index < 10000 ; index++) {
    String s = null;

    (어쩌고 저쩌고 코드)

    if (s != null ) {
 (어쩌고 저쩌고 코드)
    }
}

와 단지 null을 "" 으로 바꾸었을 뿐인데 코드를 살펴보겠습니다.

String s = null;

의 경우에 s는 스택에 위치잡게 되겠죠. null은 JVM에 항상 존재하는 오브젝트고요.

반면 ""를 지정하게 되면 ""가 힙에 잡히고, 이어서 s가 스택에 잡히게 되겠죠.

스택은 한번에 와인딩이 가능 하기 때문에 별 문제가 없지만 힙은 곤란하죠.
한마디로 쓸데없이 힙메모리를 사용하고 이 String을 가지고 연산을 반복하다보면 심지어는 힙단편화를 가져올 수 있습니다.
JVM의 메모리 관리 옵션들에 따라서 해제 시점은 상당히 밴드가 넓기 때문에 어느 순간 단편화된 힙으로 인해서
메모리를 해제하는 동안 프리징이 생길 수도 있습니다. 게다가 JVM의 캐쉬의 히트를 떨어뜨릴 수도 있습니다.

따라서 사용할지 안할 지 알 수 없는 String은 null로 초기화해야 하고
사용할 것이라고 분명히 존재지어진 문자열 연산은 가능하면 StringBuffer를 이용해야 하는 이유가 여기에 있습니다.

그런데 null이 오브젝트라서 별희안한 일들이 발생합니다. 예를 들면 이 질문글에서 처럼

System.out.print( null + "10" );

과 같은 상황인데요. 이건 null이 객체고, 객체는 toString을 가지고 있는 자바의 특성상 존재하는 자연스럽지만 기괴한 현상일 뿐입니다. 결국 String 객체가 필요한 곳에서 null 객체와 문자열을 더해버렸으니 나온 결과입니다.
재밌는 것은 이건 어디까지나 JVM이 암시적으로 null의 toString을 호출 했을 때만 가능한 현상이라는 점입니다.
우리가 명시적으로 null은 예약어임과 동시에 말그대로 널 객체라는 이유로 toString이라는 메세지를 전달할 수는 없습니다.

System.out.print( ((Object)null).toString() + "10");

와 같은 코드는 그래서 NullPointerException 을 발생시킵니다. JVM이 호출한 것과 다르게 우리는 메세지를 전달하는 개념이기 때문에 null객체에게 메시지를 전달하려고 했으니 당연한 결과겠죠.

JAVA를 설계한 사람들의 아주 섬세한 배려라고 할까요.

이는 우리에게 있어서 String 클래스를 사용함에 있어서 null로 초기화를 하게 시키고 결국

String s = null;
(어쩌고 저쩌고 코드)
if ( s != null ) {

과 같이 != null 의 사용을 부추기고 실제로 JAVA에서는 != null 이 까딱잘 못하면 매우 오용되어서 소스코드 곳곳에 != null 이 사용되는 상황을 가지고 옵니다.

흔히 이런 != null의 오용이 싫은 사람들은 String을 ""으로 초기화 하자고 하지만 이는 가벼운 프로그램에서는 상관없지만 메시브한 사용자와 상대해야 하는 프로그램에서는 힙단편화와 더 오랜시간의 가비지컬렉션수행을 가져옵니다. WAS라면 모르지만 동접이 수천인 게임서버라도 된다면 프리징은 절대 악이겠죠.

그래서 우리는 String은 null로 초기화하고 다시 한번 말하지만 문자열 연산은 StringBuffer를 이용해야 하고

String의 경우는 != null 이나 == null은 꼭 필요한 장소에서만 사용하는 습관을 길러야 합니다.
예를 들면 다음과 같은 코드죠.

public void func(String arg) {
  if (arg == null) {
   throw new NullPointerException();
  }
  
  (어쩌고 어쩌고)
 }

그리고 또 다른 중요한 점은 NullPointerException 입니다.
자바의 여러 Exception 중에서 이 NullPointerException은 좀 특이한 녀석입니다.
다른 여러 Exception과 다르게 NullPointerException을 포함하는 몇몇 Exceptioin은 catch 해주지 않으면

JVM의 메모리 관리 대상에서 빠집니다.
한마디로 가비지콜렉션이 안되고 Memory Leak이 생기게 되고, 이 메모리는 JVM이 종료가 되는 시점에서 반환이 됩니다.
주기적으로 생성하는 쓰레드에서 NullPointerException이 발생했는데 무시하고 catch 안한다면
어느순간에 JVM은 out of memory 상태가 되버릴 수도 있습니다. out of memory만 발생하면 메모리 왕창 박아서 돈으로 바른 머쉰에서는 문제가 안 될 수도 있지만 가비지컬렉션의 알고리즘을 생각하면 이는 JVM의 퍼포먼스 저하로 이어집니다. 황당하죠.
이 역시 JAVA를 설계한 사람들의 섬세한 배려(?)라고도 볼 수 있겠지요.

늦은 밤에 주저리 주저리 써봤는데 JAVA는 사실 C/C++과는 참 다른 언어입니다. Objective-C와 더 비슷한 면이 있다고 봅니다.

다시 한번 강조하지만 String의 사용은 최대한 자제해야 합니다. 별거 아닌 문자열 몇개지만 String의 연산으로 어마어마하게 많은 힙메모리가 소모됩니다.

String a = "hello";

String b = ", ";

String c = "world!";

라고 했을 때 별거 아닌데 이걸 초당 30프레임씩 더해서 OpenGL로 보내서 출력하는 함수가 있다고 합시다.

우리는 단지 a + b + c 라는 수식을 그 함수에 보내겠죠.

그런데 이 와중에 우리는 매 프레임 힙에 "hello" ", " "world!" 를 생성하고

연산과정의 중간으로 "hello ," 와 최종값으로 "hello, world!"를 추가로 생성합니다. 예상보다 어마어마하죠.

진짜 아무 것도 아닌데 JVM의 버전이나 버전별 메모리 관리 옵션에 따라서는 메모리가 몇 분간 쭉쭉쭉쭉~ 증가하다가  어느 순간에 가비지 컬렉션이 일어나면서 초당 30프레임이 안나오고 순간 프레임 드롭이 걸리는 것을 볼 수 있습니다.

일반 SI라면 별 문제가 아닐 수도 있지만 게임과 같이 프레임이 중요하다면 이는 커다란 오점이 되겠죠.

이걸 초반에 알았거나 발견했다면 별 문제가 안되고 간단하게 해결 할 수 있겠죠.

문제는 프로젝트 중반 이후에 발견했다면? 기껏하는 대책이라는게 프레임마다 강제로 플러싱을 주어서 가비지 컬렉션을 일으키는 것 뿐일 겁니다. 아니면? 용감하게 다 갈아엎던가요.

JAVA에서는 우리가 가비지컬렉션 알고리즘은 선택할 수 있지만 가비지컬렉션이 일어나는 시점은 선택할 수 없기 때문에 힙메모리는 진짜 섬세하게 사용해야 합니다.

메모리 때문에 수고들 많으시네욤;;;

그냥 프로그래밍 안하는게 가장 맘편한 생활을 할 수 있을것 같아용...;; 생각만 해도 머리아포;;

돈으로 박을 수 있는 게 행복한 거죠.

그리고 돈으로 박아서 처리해야 합니다. 라고 확실히 이야기하고 진행할 수 있는 개발자가 있다면 그 역시 행복한 거구요.

물론 그 쯤 되려면 꽤 오랜 경험이 있어야 하니깐.. 것도 큰 어려움.......

객체를 이어서 string을 만들기 때문인가 보군요.

JSP 스크립트도 결국은 String으로 처리하는 것이니, 매우 느린 경우가 되겠군요.

가끔 서버가 프리징 때문에 중지되는 경우가 있어서 현재 GCor 만 바꾼 상태인데...이런 경우는 어떻게 처리해야 할까요?

실제 Massive String Concate 때문에 서버가 죽은 경우가 있어서, 왠만한 건 다 SB 를 사용했는데, 이것마저도 프리징 된다면 GCor 를 바꾸는 것 외에는 무엇을 해야 할 수 있을지 두렵네요.