เพิ่งอ่าน blog เรื่อง Why 1000 == 1000 Returns False, but 100 == 100 Returns True in Java ?
แค่เห็นชื่อเรื่องก็งง แต่แอบน่าสนใจ สำหรับ Java Puzzle
โดยใน blog อธิบายที่มาที่ไปได้อย่างน่าสนใจ
ซึ่งน่าจะทำให้เราเข้าใน Java ดีขึ้นมาอีกนิดนึง
ดังนั้นมาดูกันหน่อย ว่าทำไมถึงเป็นเช่นนั้น
มีการพูดคุยใน Facebook ที่นี่
[fb_embed_post href=”https://www.facebook.com/somkiatspns/posts/10153769789653588/” width=”550″/]
ปัญหามันเกิดจาก code ชุดนี้
เป็น code ที่น่าสนใจ และ น่าค้นหาอย่างมากมาย
ลองคิดเล่น ๆ ว่า ผลการทำงานจะเป็นอย่างไร ?
…
ผลการทำงาน คือ
false
true
มาถึงตรงนี้เล่นเอางงไปเลย !!
ทำไม 100 == 100 แล้ว
ทำไม 1000 != 1000 ล่ะ
แบบนี้มันลำเอียง หรือ ทำงานไม่ถูกต้องหรือเปล่า ?
โดยพื้นฐานของภาษา Java สำหรับการใช้งาน ==
จะเท่ากัน หรือ ผลที่ได้คือ true ก็ต่อเมื่อทั้งสอง object ชี้ไปยังตำแหน่งเดียวกัน
และมีค่าเท่ากัน ดังนั้น จากความรู้นี้ ผลที่ควรได้คือ
false
false
แต่การทำงานจริง ๆ มันไม่ตามทฤษฎีเลยนะ
ซึ่งเป็นสิ่งที่น่าสนใจอย่างมาก
ดังนั้นมาหาเหตุผลกันดีกว่า
ด้วยการเปิดดู source code ของ Integer.java กัน
ซึ่งเราจะดูที่ method valueOf()
จาก code จะเห็นว่ามีการเรียกใช้งาน property จาก class IntegerCache ด้วย
คำถามที่เกิดขึ้นมา ก็คือ
- IntegerCache.high มีค่าเท่าไร ?
- IntegerCache.low มีค่าเท่าไร ?
เมื่อเข้าไปดูมันคือ inner private class อยู่ใน Integer.java นั่นเอง
ซึ่งได้ความว่าค่า default ของแต่ละ property เป็นดังนี้
- IntegerCache.high =127
- IntegerCache.low = -128
ซึ่งตรงนี้นี่เอง เป็นเหตุผลที่ว่า ทำไม
Integer c = 100, d = 100;
จึงเป็น object ที่อ้างถึงตำแหน่งเดียวกัน
ทำให้ผลที่ได้จาก c == d เป็น true
คำถาม ทำต้องทำ Caching ด้วยล่ะ ?
คงต้องไปถามทีมสร้างละมั้ง !!
แต่ถ้าลองพิจารณาด้วยเหตุและผล ก็น่าจะได้คำตอบว่า
เพราะว่าตัวเลขช่วงนี้มันเล็ก ๆ ซึ่งมีโอกาสใช้งานบ่อย ๆ
รวมทั้งต้องการลดจำนวน memory ที่ใช้งานด้วย
ดังนั้น caching มันไว้เลย !!
ลองไปดูใน JavaDoc ก็พบว่ามีมาตั้งแต่ Java 1.5 นะครับ
เป็นเรื่องที่ไม่เคยรู้เลยว่า การทำงานภายในของ Integer มันเป็นแบบนี้
