Example.java

Views.java

출처 : https://gist.github.com/gelitenight/7999448

0. 들어가기 전에

 자바에서 String 문자를 더해가는건 큰 이슈가 있습니다. 보통 사람들은 String 에서 +를 이용하여 문자를 결합합니다. 이 방법은 작은 규모의 몇백자 정도로는 그렇게 큰 차이를 보이지 않을지도 모르지만 잘 모르고 쓴다면 작은 규모에서도 큰 차이를 보여줍니다. 이번에는 그 차이를 한번 따져보려고 합니다.  

1. 이론적인 차이

 1-1. String의 경우 

자바에서 String은 Immutable(불변의) 속성을 가지고 있습니다. 우리는 보통 String을 저장할 때 이렇게 합니다.

위와 같이 한다면 name에 있던 펭귄이라는 치킨으로 수정되는 것 처럼 보이지만 내부적으로는 수정되는 것이 아니라 새로운 메모리를 잡고 치킨이라는 값을 저장한 후 그 곳을 가리키는 방식이 됩니다.

 + 연산자로 더하는 작업도 마찬가지입니다.

새로운 메모리를 할당하여 그곳에 심해펭귄 이라는 글자를 저장하고 name이 그곳을 가리키게 한 후 기존의 펭귄이 저장된 메모리를 Garbage Collection이 제거해줍니다. 

단순히 문자를 몇개 더하는 경우도 이 과정을 거치지만 몇번 이내로 끝나는 횟수라면 굳이 다른 것을 쓰지 않으셔도 됩니다. (StringBuilder가 빠르지만 ns 단위의 차이입니다.) 다만 긴 문자를 몇 백번 이상 더할 경우에는 성능이 내려갈 수 있으므로 StringBuilder나 StringBuffer를 써주시는게 좋습니다. 

JDK5 이상의 버전부터는 String도 내부적으로 StringBuilder로 바꿔서 컴파일한다고는 하는데 막상 해보면 그다지 차이가 없습니다. 

1-2. StringBuilder와 StringBuffer의 경우

 StringBuilder와 StringBuffer는 String 과 다르게 가변의 속성을 가지고 있습니다. 그래서 할당된 공간에 계속 이어가는게 가능하며, append 메소드를 이용하여 문자를 추가합니다. 또한 할당된 공간이 오버플로우가 발생한 경우에는 자동으로 할당된 공간을 확장합니다. 

(이때 오버해드가 발생하여 속도가 약간 저하되는 듯 합니다.)

 StringBuilder의 경우 StringBuffer와 달리 동기화 된다는 보장을 하지 않지만 StringBuffer보다는 조금 빠른 속도를 보여줍니다.

만약 멀티 스레드를 사용하는 경우에는 동기화를 해야하는 경우가 생기는데  이 경우에는 StringBuffer를 이용하여야 합니다. StringBuffer는 멀티 스레드 작업에 대해서 안전하게 만들어져 있습니다. 하지만 일반적인 경우에는 멀티 스레드를 사용할 일이 별로 없으므로 StringBuilder를 사용하시면 되겠습니다.

2. 실제 속도 차이

속도를 계산하는 간단한 소스를 짜봤습니다. 글자수는 10자를 기준으로 하여 횟수를 조정하여 총 100자부터 10만자까지 더하도록 하겠습니다. 같은 시행횟수라도 시행때마다 값의 차이가 생깁니다. 하지만 그 차이는 그렇게 크지 않으며, 그 흐름 또한 일치하므로 오차가 조금 있을 수 있다 정도는 염두해 두시면 되겠습니다. 추출한 값은 ns로 추출하였지만 후반의 숫자가 매우 크므로 ms로 변환하여 표기하도록 하겠습니다.

10개자리 문자를 시행횟수만큼 더한 결과입니다.

문자를 10개 정도 더해도 String이 builder나 buffer보다 3-4배 정도 느린걸 알 수 있습니다. StringBuffer의 경우 처음 버퍼를 생성하는 시간 때문인지 첫 시행때 다소 시간이 걸립니다.

builder와 buffer가 속도가 느려졌다 빨라졌다 하는건 할당한 메모리가 다 차서 메모리를 늘려주는 작업을 하기 때문인 듯 합니다. 

시행횟수가 백번 이상으로 넘어가면 속도차이가 확연하게 벌어집니다. Builder와 Buffer는 그렇게 큰 차이가 나진 않지만 String과의 차이는 40배 이상으로 벌어졌습니다.

시행횟수가 1000이 넘어가면 String과의 격차는 몇백배 입니다.

시행횟수가 10만이 되면 String은 너무 느려서 쓸 수 없습니다. 1000ms = 1초인데 62000ms라면 62초나 걸리게 됩니다.

문자가 200만개가 되니 610000 ms가 걸렸습니다. 610초 즉 10분입니다.

덤으로 1개짜리 문자를 10000번 더하는 것이 100개짜리 문자를 100번 더하는것보다는 오래 걸리며, 100자짜리 문자를 100번 더하는 것이, 10자짜리 문자를 100번 더하는 것보다 오래 걸립니다.

펌 : http://blog.naver.com/platinasnow/220197411183

** CharSequences 인터페이스

CharSequences는 인터페이스로 String/StringBuffer/StringBuilder 세가지 클래스는 모두 

CharSequences 인터페이스를 상속받고 있습니다.

때문에 Charsequence에는 위 3가지 클래스를 모두 수용할 수 있습니다.(Up-casting)

또한 사용할 때에는 down-casting 해서 사용하시면 됩니다.

String/StringBuffer/StringBuilder 세가지 클래스를 매개변수로사용하는 함수라면 매개변수를 Charsequence로 해주는 좋겠죠?

펌 : http://blog.naver.com/tkddlf4209/220706609022

Collection Framework는 크게 3가지 형태로 분류할 수 있다.
  - Map  : key와 Value를 가지는 자료구조입니다. HashMap, Hashtable, TreeMap 등
  - List  : 순서가 있고 중복이 허용되는 자료구조입니다. ArrayList, LinkedList, Vector 등
  - Set   : 중복을 허용하지 않습니다.  HashSet, TreeSet 등

인터페이스에 대한 hierarchy관계를 이해하고 사용예제를 통해 각 인터페이스에 대한 특성을 확인해 보도록 한다.

[그림 3] Collection Interface 구성도

기본적으로 Collection의 경우 연속된 순서의 선형 자료형을 구현한 인터페이스이며, MAP은 Key, Value를 다루는 자료형을 구현한 인터페이스 이다. 기존에 구현된 Vector와 Hashtable의 경우, Synchronized를 지원하도록 설계되었기 때문에 다중 스레드 접근 시 병목현상을 유발할 수 있기 때문에 유의해서 사용하도록 한다.

** Collections Synchronized 

import java.util.*;

public class SynchronizedCollectionTest {
   public static void main(String[] args) {
       // create vector object
       List<String> list = new ArrayList<String>();

       // populate the list
       list.add("1");
       list.add("2");
       list.add("3");
       list.add("4");
       list.add("5");

       // create a synchronized list
       List<String> synlist = Collections.synchronizedList(list);
       System.out.println("list :"+synlist);
   }
}

참고 : http://rocksea.tistory.com/336
        http://whosnext.blog.me/100037993078

이전에 쓴 기록 : 2011.04.06 17:55 

마이크로소프트잡지 :   http://www.imaso.co.kr/?doc=v2/index.php

디씨인사이드 프갤 : http://gall.dcinside.com/list.php?id=programming&no=222920&page=1&bbs=

클리앙 : http://clien.career.co.kr/

블로터닷넷 : http://www.bloter.net/

다양한 공식적인 프로그래밍 대회가 있지만

참고로 아시아권에서 펼쳐지는 프로그래밍 대회로 ACML 라는 게 있습니다.

그리고 코드포스 (code forces) 라는 (https://codeforces.com/)

프로그래밍 경시대회? 혹은 프로그래밍 올림피아드 같은 비공식 대회가 있습니다.

https://ironmask.net/279 에서 한번 간략히 소개를 했었네요 ㅋㅋ

저는 2016년에 가입을 햇었고 사내 프로그래밍 대회에 참여를 해보려는 심산이었죠 ㅎㅎ

생각보다 프로그래밍에 그렇게 취미를 붙이기는 쉽지 않아서

결국 2문제 도전 해보고 포기했네요 ㅜㅜ

그 중 처음으로 풀어서 문제 조건을 해결해낸 문제가 아래 문제입니다.

http://codeforces.com/contest/615/problem/A

보통 프로그래밍 대회에서 나올법한 문제들은,

대량의 연산을 요구하고, 이를 빠른 수행이 완료될 것을 요구합니다.

그리고 실제대회에서는 이러한 문제를 시간내에 풀어야 하죠 ㅜㅜ

사실 문제 풀 시간을 무한정 주더라도 문제 풀어내기가 힘든 레벨입니다. ㅋ

프로그래머를 직업으로 했던 저로서는 부끄러운 일 일지 모르겠습니다만,

원래 하던 코드만 만지다 보면 이런 코드 상당히 어렵습니다.

참고로, 국정원에 도전해본적이 있었는데,

실기 시험문제가 비슷한 방식의 문제들이었던 것 같네요.

아래는 해결했던 코드입니다.

사실 Java보다 C나 C++로 해야 더욱 빠른 해결 접근법이 가능합니다만,

이때부터 Java가 주력언어가 되어서 Java로 해결했습죠..

언젠가 다시..

프로그램 개발을 Job으로 하는 날이 올거라고 생각합니다..

물론 수준 높은 처우와 함께.. ^^

기초부터 쌓아올려서 다시금 이 때 레벨까지 올라가서

Codeforces를 재방문하는 날이 기다려지네요!

* 애플의 새로운 오픈소스 생태계 제안 - swift 
-> https://swift.org/

* 기술면접 리스트
http://navercast.naver.com/contents.nhn?rid=122&contents_id=115489 - 네이버 캐스트 정보기술편

http://cafe.naver.com/itstudy000/19  (기출면접 리스트)

http://ejunghyun.tistory.com/133

* Java Algo.
http://manducku.tistory.com/21

* Java Collections 

http://enjoyjava.tistory.com/entry/Java-Collection-Framework-Overview -> Java API Doc를 참고한 JCF  목록 정리

                                                                                 여기서 더 심화로 레드블랙트리와 해쉬구조 궁금
http://blog.naver.com/elize92/10181228722 -> 대박 정리 잘되어있음...

http://nana4you.egloos.com/1767543        <- Vector, HashTable 성능비교

http://cymkan.blog.me/133236554            <- Map 예시

* 퀵소트

http://blog.naver.com/software705/220674750339

http://blog.naver.com/maniaclub/80014086950

Codeforce라는 프로그래밍 대회를 개최하는 사이트가 있습니다.

저는 어제 알았네요..

사이트는 아래와 같습니다. 

http://codeforces.com/

가입은 Gmail 계정이 있으면 바로 인증이 가능합니다.

러시아에서 만든 사이트라고 들었으며, 대회 주최는 누구나 문제를 만들어서 할 수 있다고 합니다..

관련 소개 참고 : http://blog.naver.com/yechan54/10157522544
                      http://blog.naver.com/onjo0127/220598539332

대학 졸업 후 경력에 비해 코딩력이 그대로거나 오히려 떨어졌을지도 모른다는 생각이 들어서...
코딩스터디도 하며, 준비도 해보려 합니다. ㅎㅎㅎ

앞서 안드로이드 플랫폼에서 리소스에 따른 정책에 대해 공유드렸습니다.

이번엔 그러한 정책에 따른 해상도별 관리를 어떻게 하는 것이 좋을지에 대해 공유 드립니다.

이번에도 이미 잘 정리해놓으신 분들의 글을 좀 퍼왔습니다. (http://arabiannight.tistory.com/entry/293 펌)

아직 앱 개발 초보라 모르는 것이 많아서 ㅠㅠ..

사실 안드로이드 플랫폼을 탑재한 모든 기기(모바일 폰, 태블릿 등등)에 대해 해상도를 최적으로 맞추기는 불가능한 수준입니다. 그래서 최대한 여러 해상도를 커버하기 위한 방법에 대해 생각해보면 아래와 같습니다.

[범용 해상도 맞추는 법]

1) 해상도별 폴더를 만들어라.

-> 안드로이드 단말만 수천개 이상, 현실적으로 불가능.

-> 타겟 단말을 지정해서 개발 해라. 

[범용 해상도를 최대한 고려한 작업 방법]

1) match_parent를 잘 활용 하라.

2) weight를 사용하라.

3) RelativeLayout을 사용 하라.

-> align, parent, below, above 등의 속성를 사용하라.

4) dp값을 활용하라.

5) 나인패치를 활용하라.

6) 통이미지라면 큰 이미지를 사용해서 작은 화면에 적용 하라.

7) Scrollview를 잘 활용하라.

나인패치 관련
개념 :  http://blog.naver.com/purplestudiogames/220605836258 참고

적용 :  http://bcho.tistory.com/1059 참고

AndroidManifest.xml 파일에 속성 중에 리소스 identifier 와 비슷한 속성 설정이 있는데 아래와 같다.

android:configChanges 값이 아무것도 없을 때는 단말을 돌려서 단말 표시 모드가 portrait mode -> landscape mode 가 되면 위에서 설명된 것과 같이 기본 동작은 Activity 가 destroy 되었다가 다시 시작합니다.

android:configChanges = "orientation" 이 설정되면, portrait mode -> landscape mode 가 되어도, Activity는 destroy 되지 않습니다. 대신에 Activity에 override 된 onConfigurationChanged() 함수가 호출되며, 여기서 환경변화 ( config changes ) 에 대한 처리를 해줍니다.

 가장 흔하게 접할 수 있는 경우가 위에서 예를 든 orientation changes 경우입니다.

마찬가지로 흔하게 접할 수 있는 것이 keyboardHidden 입니다.
keyboardHidden 은 hardware keyboard가 보이냐 안 보이냐에 따라서 발생하는 변화입니다.

가장 대표적인 hardware keyboard를 갖춘 device인 옵티머스 Q를 보면, 슬라이드 형식으로 QWERTY 자판을 꺼냈다 숨겼다 할 수 있죠.
이 때 변화가 없어도 되는데 쓸데 없이 Activity 가 파괴되고 생성되면 안 되겠죠? 그래서 QWERTY 자판이 있을 경우는 거의 대부분 이 attribute 설정이 필요하게 됩니다.

그 외에도 configChanges 가 발생했을 때 단순한 Activity의 재시작 이외에 추가적 작업을 해 줄 때에도 사용됩니다.

먼저 configChanges에는 여러가지 값들을 '|' ( or ) 구분자를 통해서 함께 입력 가능합니다.

펌 : http://aroundck.tistory.com/36

Sony A5100 추천 -> 세트로 대략 60만 정도

-> 16-50mm렌즈 포함하고 기본패키지 가방+UV필터+리더기+16GB SDHC 카드+LCD필름 로 해서 70만정도로 구입

네이버 까페 모임이 있음

--> http://cafe.naver.com/a350club

** 아래는 비교 참고

사실 저런 용도에서는 딱히 크게 괜찮다 괜찮지 않다 로 나누긴 애매합니다.

화질적 성능은 한단계 아랫급인 nex-3n이나 신형인 a5000,

상급기종인 5T나 신형인 a5100이나 엇비슷합니다.

저런 데일리 샷 정도는 더더욱 차이를 느끼기가 힘들겠죠.

저런 스타일의 사진은 폰카로도 많이 찍으니까요.

정적인 샷이니 사실상 AF성능 면도 크게 따질건 없겠죠.

굳이 사용편의성을 따지면

아랫급 기종들은 터치가 안먹고 3n은 와이파이가 없습니다.

5000은 와이파이가 있어 좀 더 유리합니다.

5t와 5100은 터치가 있고 와이파이가 있습니다.

5100이 AF면에서 더 유리합니다.

화질적 성능은 제쳐두고 사용 편의성이 더 좋아졌다 보시는게 편합니다.

3n은 그냥 무난하고 평범한 성능

5000은 거기에서 와이파이가 추가되 바로 폰 등으로 옮겨 업로드나 편집이 가능

5t는 거기서 터치 추가

5100은 AF가 빨라지므로 애완동물 등 동적인 것을 찍는데도 좀 유리...

- default 리소스와 hdpi 대체 리소스 -

아래 표는 어플리케이션이 가지고 있는(프로그래머가 제공해준, 어플이 제공해줄수 있는) 이미지 resource들과,

실제 디바이스(기기)의 환경입니다.

images	device configuration
drawable/ drawable-en/ drawable-fr-rCA/ drawable-en-port/ drawable-en-notouch-12key/ drawable-port-ldpi/ drawable-port-notouch-12key/	Locale = en-GB  Screen orientation = port  Screen pixel density = hdpi  Touchscreen type = notouch  Primary text input method = 12key

실제로 안드로이드는 아래의 플로우 차트를 통해 리소스를 찾아내고 매칭합니다.

1번. 기기 환경과 모순되는 것들 제거하기   Locale이 en-GB로 설정되어있기 때문에   drawable-fr-rCA/ 디렉토리를 제거합니다. drawable/ drawable-en/ drawable-fr-rCA/ drawable-en-port/ drawable-en-notouch-12key/ drawable-port-ldpi/ drawable-port-notouch-12key/  2번. MCC, MNC, Language,        그리고 나머지 순으로 Qualifier 확인하기  3번. 분기.       (qualifier 중 포함되어있는 디렉토리 찾기)          매칭되었으면 4번으로,         매칭되지 않았으면 2번으로 돌아가기  4번. 포함되어있지 않은 Qualifier 제거하기   lanuage qualifier 가 포함되어있지 않은 디렉토리 제거     drawable/ drawable-en/ drawable-en-port/ drawable-en-notouch-12key/ drawable-port-ldpi/ drawable-port-notouch-12key/  5번. 하나의 디렉토리로 매칭될때까지 계속하기   계속해서 2번, 3번, 4번의 스텝을 반복하게 되면,   결국에는 drawable-en-port 만 남게됩니다. drawable-en/ drawable-en-port/ drawable-en-notouch-12key/

퍼옴 : http://croute.me/323

원글 : http://developer.android.com/guide/topics/resources/providing-resources.html

응용 프로그램 리소스를 독립적으로 유지하기 위해, 코드에서 이미지와 문자열과 같은 리소스를 구체화해야 한다. 또한 특별한 이름이 붙여진 리소스 디렉토리들 내에서 그것들을 그룹화하여, 특정한 디바이스 구성(Configuration)을 위해 대안적인 리소스들을 제공해야한다. 안드로이드는 실행시간에 현재 구성에 바탕을 둔 적합한 리소스를 사용한다. 예를 들어 화면 크기에 따라 다른 UI 레이아웃을 사용하거나 셋팅된 언어에 따라 다른 문자열이 제공되기를 기대할 수 있다.

일단 응용 프로그램 리소스를 구체화하면, 프로젝트의 R 클래스 내에 만들어진 리소스 ID들을 사용하여 리소스에 접근이 가능하다. 응용 프로그램에서 리소스를 사용하는 방법은 Accessing Resources에서 확인할 수 있다. 이 문서는 어떻게 안드로이드 프로젝트 내의 리소스들을 그룹화 하고 특정 디바이스 구성을 위한 대안적인 리소스들을 제공하는지 보여준다.

리소스 유형 그룹화

프로젝트의 /res 디렉토리의 특정 하위 디렉토리에 각 타입의 리소스를 배치해야 한다.

MyProject/
    src/
        MyActivity.java  
    res/
        drawable/  
            icon.png  
        layout/  
            main.xml
            info.xml
        values/  
            strings.xml 

이 예에서 볼 수 있듯이, 하나의 이미지 리소스(icon.png), 두 개의 레이아웃 리소스(main.xml, info.xml), 하나의 스트링 리소스 파일들(strings.xml) 등 /res 디렉토리는 (하위 디렉토리들 안에) 모든 리소스를 포함한다. 리소스 디렉토리 이름은 중요하며 표 1에 설명되어 있다.  

표 1. 프로젝트 res/ 디렉토리 내에 지원되는 리소스 디렉토리

주의 : /res 디렉토리 내에 직접적으로 리소스 파일을 저장하지 않도록 한다. 이는 컴파일 에러의 원인이 된다.

리소스 타입들에 대한 더 많은 정보는, Resource Types 문서를 참조한다.

표 1에 정의된 하위 디렉토리들 내에 저장한 리소스들은 당신의 "디폴트" 리소스들이다. 즉 이 리소스들은 응용 프로그램의 기본 디자인과 컨텐츠를 정의한다. 그러나 다른 타입의 안드로이드 디바이스들은 다른 타입의 리소스들을 요구할지 모른다. 예를 들어 디바이스가 일반적인 화면보다 더 큰 화면을 졌다면, 추가 화면 공간을 용한 다른 레이아웃 리소스들을 제공해야 한다. 또 디바이스가 다른 언어로 셋팅되어있다면, 사용자 인터페이스에서 텍스트를 번역한 다른 스트링 리소스들을 제공해야 한다. 다른 디바이스 구성에 대해 다른 리소스들을 제공하기 위해, 디폴트 리소스뿐 아니라 대안적인 리소스들을 제공할 필요가 있다.

대안적인 리소스 제공

거의 모든 응용 프로그램은 특정 디바이스 구성을 지원하기 위해 대안적인 리소스들을 제공해야한다. 예를 들어, 다른 화면 밀도를 위해 대안적인 드로어블 리소스와 다른 언어를 위한 대안적인 스트링 리소스를 포함해야 한다. 실행 시간에 안드로이드는 현재 디바이스 구성을 발견하고 적합한 리소스들을 로드한다.

그림 1. 각각 다른 레이아웃 리소스를 사용하는 두 개의 다른 디바이스들 

리소스 셋에 대해 

1. <resources-name>-<config_qualifier> 내에 명명되어진 res/ 내에 새로운 디렉토리를 만들어라. 

ㅁ <resources_name>은 (표 1에 정의된)디폴트 리소스들에 대응하는 디렉토리 명이다. 

ㅁ <qualifier>는 (표 2에 정의된) 리소스가 사용되는 개인 컨피규레이션을 지정한 이름이다. 

대쉬로 각각 분리해서 <qualifier>를 하나 이상 추가할 수 있다. 

주의 : 다수의 한정자를 덧붙일 때, 표 2에 목록으로 만들어진 동일한 차수 내에서 그것들을 배치해야 한다. 한정자가 틀리게 지시받으면, 리소스들은 무시된다. 

2. 이 새로운 디렉토리 내에 각각의 대안 리소스들을 저장하라. 리소스 파일들은 디폴트 리소스 파일들과 정확히 동일한 이름을 지정해야 한다. 

예를 들어, 여기 디폴트 리소스와 대안 리소스가 있다: 

res/
    drawable/   
        icon.png
        background.png    
    drawable-hdpi/  
        icon.png
        background.png 

hdpi 한정자는 고밀도 스크린을 가진 디바이스에 대한 디렉토리 내의 리소스들을 나타낸다. 각 드로어블 디렉토리들 내의 이미지들은 특정한 스크린 밀도를 위해 크기에 따라 분류된다. 그러나 파일 이들들은 정확하게 동일하다. 이 방법으로, icon.png나 background.png 이미지를 참조하는데 사용하는 리소스 ID는 항상 동일하다. 그러나 리소스 디렉토리 이름 내에 한정자로 디바이스 구성 정보를 비교하며 안드로이드는 현재 디바이스와 가장 잘 맞는 리소스 버전을 선택한다. 

안드로이드는 몇몇의 구성 한정자를 제공하고 당신은 대쉬로 각 한정자를 분리시킴으로써 하나의 디렉토리 이름에 다수의 한정자를 추가할 수 있다. 표 2는 유효한 구성 한정자를 우선 순위 차례대로 목록으로 보여준다. 리소스 디렉토리에 대해 다수의 한정자를를 사용한다면, 그것들이 표에 리스트된 순서대로 디레곹리 이름에 그것들을 추가해야 한다. 

퍼옴 : http://blog.naver.com/PostView.nhn?blogId=mad_ai&logNo=130165607607

Primitive type과 Reference type 그리고 Object 클래스

Primitive type (원시타입)

● 자바 언어에 내장된 기본 유형 
● 자바는 정수, 실수, 논리, 문자 방식의 primitive type을 지원한다. 
● wrapper class는 각 primitive type을 클래스로 만든 것이다. 
● stack 메모리에 저장됨. 

■ byte 

• 8 비트 크기에 부호있는 정수
• 표현할 수 있는 범위는 -128 ~ 127
• 2의 보수로 메모리에 저장됨
• 기본값 : 0
• wrapper class : Byte

■ short 

• 16 비트 크기에 부호있는 정수
• 표현할 수 있는 범위는 -32,768 ~ 32,767
• 2의 보수로 메모리에 저장됨
• 기본값 : 0
• wrapper class : Short

■ int 

• 32 비트 크기에 부호있는 정수
• 표현할 수 있는 범위는 -2,147,483,648 ~ 2,147,483,647
• 2의 보수로 메모리에 저장됨
• 주로 사용
• 기본값 : 0
• wrapper class : Integer

■ long 

• 64 비트 크기에 부호있는 정수
• 범위는 -9,223,372,036,854,775,808 ~ 9,223,372,036,854,775,807
• 2의 보수로 메모리에 저장됨
• 기본값 : 0L
• wrapper class : Long

■ float 

• 32 비트 크기에 실수
• IEEE 754 표준을 따릅니다.
• 부동소수점 방식으로 메모리에 저장됨
• 화폐와 같이 정확한 값을 요하는곳에 double을 사용하면 안됨
• 기본값 : 0.0f
• wrapper class : Float

■ double 

• 64 비트 크기에 실수
• IEEE 754 표준을 따릅니다.
• 부동소수점 방식으로 메모리에 저장됨
• 화폐와 같이 정확한 값을 요하는곳에 double을 사용하면 안됨
• 기본값 : 0.0d
• wrapper class : Double

■ boolean 

• true와 false의 두 가지 값을 가지는 논리형
• 참 / 거짓 상태를 판별하기 위한 간단한 flag로 boolean을 사용합니다.
• 1bit의 정보를 표현하지만, 사용하는 메모리 크기는 정확히 정해져 있지 않습니다.
• 기본값 : false
• wrapper class : Boolean

■ char 

• 16 비트 유니 코드 문자
• 범위는 0 ~ 65,535 혹은 '\ u0000' ~ '\ uffff'
• 기본값 : ‘\u0000’
• wrapper class : Character

Reference type

• 클래스 타입(class type), 인터페이스 타입(interface type), 배열 타입(array type), 열거 타입(enum type)
• Ball 클래스의 참조형 변수를 선언 : Ball b; → Ball 클래스 인스턴스를 생성 후 참조형 변수에 할당 : b = new Ball(); → heap 메모리에 저장.
• 힙 메모리에 생성된 인스턴스는 메소드나 각종 인터페이스에서 접근하기 위해 JVM의 Stack 영역에 존재하는 Frame에 일종의 포인터(C의 포인터와는 다르다.)인 참조값을 가지고 있어 이를 통해 인스턴스를 핸들링한다.
• 그래서 참조형 클래스 사용 시 아래의 변수 할당 방식을 사용시 할당된 변수가 변경되는 원소스에 해당되는 변수도 같이 변형된다. 그래서 원소스에 해당되는 인스턴스와 별개로 할당 변수를 사용하기 위해서는 clone 내지 별개의 힙 메모리에 복사를 하여 사용하는 것이 안전하다.

• JVM과 메모리 구조 챕터에서 생성과 소멸 등의 과정 참조

Object Class

• 클래스 계층구조의 루트 클래스
• Primitive type이 아닌 모든 type(배열 포함)이 Object 클래스를 직접, 간접적으로 상속합니다.
• Object 클래스는 JVM(특히 Execute Engine / Garbage collector)에서 클래스 인스턴스의 생성과 소멸 등의 생명주기(life cycle)을 관리할 수 있게 한다.
• 클래스의 생성자 Object 클래스의 finalize(), wait() 등 대부분의 메소드가 JVM에서 클래스를 핸들링하기 위해 사용되는 메소드다.
• 참조형 변수(클래스)들은 기본적으로 Object를 상속하기 때문에 모든 클래스의 인스턴스의 라이프사이클을 관리할 수 있게 된다.

• Object 클래스의 메소드

String 클래스

• 문자열을 primitive type 처럼 사용할 수 있도록 String 클래스를 특별하게 처리함. 즉, String 클래스는 일종의 Primitive 타입(원시타입)처럼 사용 가능하지만 원시타입에는 속하지 않는다.
• String 클래스는 값이 변경되지 않으며, 값을 변경하는 함수가 있지만, 이 함수는 값이 다른 String 클래스 객체를 생성한다. (immutable object)
• String s = “aaa”; 와 같이 큰따옴표를 사용하여 생성자를 호출할 수 있다.
• String 클래스만이 + 연산자를 통해 문자열 연결
• String 비교시 equals() 함수 사용
• String class의 사용 예제 : 첨부 소스 참조

http://www.gliderwiki.org/wiki/79  펌