มีสองสามวิธีในการสร้างรายการ

• Arrays.asList(…)
• List.of(…)
• Collections.unmodifiableList(…)
• Collections.singletonList(..)
• new ArrayList(…)

เพื่อให้บทความทั้งหมดสมบูรณ์ เราจำเป็นต้องเรียกใช้รหัสนี้ การทดสอบจะแสดงการดำเนินการที่ถูกต้องและมีข้อยกเว้น รหัสไม่สะอาด แต่ทำงาน

Arrays::asList

ส่งคืนรายการขนาดคงที่ซึ่งได้รับการสนับสนุนโดยอาร์เรย์ที่ระบุ (เปลี่ยนรายการส่งคืน "เขียนผ่าน" ไปยังอาร์เรย์) เมธอดนี้ทำหน้าที่เป็นสะพานเชื่อมระหว่าง API แบบอาร์เรย์และแบบคอลเลคชัน ร่วมกับCollection.toArray(). รายการที่ส่งคืนเป็นแบบซีเรียลไลซ์ได้และนำRandomAccessไป ใช้ — asList เอกสาร

เริ่มต้นด้วยasListการดำเนินการ นี่คืออาร์เรย์คงที่โดยมีค่า 'A' และ 'V' ในตัวอย่างต่อไป เราจะเห็นตัว เลือก "เขียนผ่าน"เช่นกัน

ผลลัพธ์สำหรับการรันasListการดำเนินการ ด้วย JDK 11:

เราเห็นอะไรจากบันทึก? เราเห็นว่าจำนวนอักขระไม่เปลี่ยนแปลง อย่างไรก็ตาม เราสามารถเห็นวิธีการบางอย่างที่ไม่มีข้อยกเว้น ทำไม พวกเขาไม่ได้เพิ่มหรือลบตัวอักษรออกจากรายการ

มองใกล้ขึ้น วิธีการที่ไม่ทำให้เกิดข้อยกเว้นคือretainAll, removeAll, sort. การรักษาองค์ประกอบทั้งหมดจะไม่ทำให้เกิดการเปลี่ยนแปลงขนาด ดังนั้นจึงไม่มีข้อยกเว้นเกิดขึ้น

อะไรทำให้เกิดข้อยกเว้น? การโทรretainAllด้วยรายการที่ว่างเปล่า โทรremoveAllรายการเดียวกัน. ลักษณะการทำงานนี้เปลี่ยนขนาดของรายการ

ทำไมไม่โยนข้อยกเว้นset? เพราะคุณสมบัติ" การ เขียนผ่าน" อาร์เรย์ที่ใช้ในการเปลี่ยนแปลงสามารถ คือการดำเนินการเพื่อเปลี่ยนแปลงreplaceAllasListset

asListสร้างคอลเลกชันขนาดคงที่ ค่าสามารถเปลี่ยนแปลงได้ คุณไม่สามารถลดอาร์เรย์จริงได้

รองรับ อะไรอีกasListบ้าง? การ เพิ่มnullsลงในรายการ พฤติกรรมที่ไม่ถูกต้องในวิธีการรวบรวมอื่นๆ ทำไม nullsในคอลเลกชันสร้างความคลุมเครือ สมมติว่าเราได้รับnullกุญแจxในแผนที่ หมายความว่าเราไม่มีกุญแจxบนแผนที่ใช่หรือไม่? นั่นหมายความว่าไม่มีค่าสำหรับคีย์xหรือไม่?

การหลีกเลี่ยงnullเช็คนำมาซึ่งอะไร? ประสิทธิภาพที่ดีขึ้น asListในขณะที่การศึกษานี้สำรวจมีประสิทธิภาพดีกว่าคู่ที่ไม่เปลี่ยนรูป

คุณสามารถใช้วิธีนี้ในการสร้างรายการได้เมื่อใด เมื่อขนาดไม่เปลี่ยน แต่ค่าเปลี่ยนได้ ฉันจะใช้สิ่งนี้สำหรับกระดานเกมขนาดคงที่ แต่ละองค์ประกอบอาจเปลี่ยนแปลงได้ แต่ขนาดไม่ควร

รายการของ

List::of เปลี่ยนแปลงไม่ได้อย่างสมบูรณ์ ทั้งขนาดและมูลค่าตามจริง ทุกวิธี throws UnsupportedOperationExceptionโดยไม่คำนึงถึงอาร์กิวเมนต์

Stuart Marks ระบุว่าList::ofมีคอลเลกชันที่ไม่เปลี่ยนรูป องค์ประกอบไม่ได้ต่อตัวไม่เปลี่ยนรูป ค่าดั้งเดิมถูกห่อหุ้มไว้และไม่สามารถเปลี่ยนแปลงได้

ใช้List::ofเพื่อสร้างรายการการกำหนดค่า เมื่อคุณจำเป็นต้องตั้งค่าเป็นหิน

คอลเลกชัน::singletonList

ลักษณะการทำงานนี้คล้ายกับList::ofสำหรับ เราไม่สามารถเปลี่ยนขนาดได้ และค่าต่างๆ จะต้องไม่เปลี่ยนแปลง

ข้อยกเว้นretainAll, removeAll, sortคือ พวกเขาไม่เปลี่ยนรายการที่ตัด ดังนั้นจึงไม่มีข้อยกเว้น

พฤติกรรมประหลาดอย่างหนึ่งของsingletonList. คุณสามารถใส่nullลงในsingletonList. ทำไมมันแปลก? nullจะหลีกเลี่ยงสำหรับคอลเลกชันทั้งหมด ยังไง ก็singletonListถือnullได้

จากการทดลองsingletonListจะเร็วList::ofกว่า นี่ไม่ได้หมายความว่าเราไม่ใช้List::ofสำหรับรายการซิงเกิลตัน เราต้องการList::ofรายชื่อซิงเกิลตันเมื่อใด เมื่อคุณสร้างรายการแบบไดนามิก ใช้List::ofเมื่อคุณต้องการให้แน่ใจว่ารายการซิงเกิลตันมีnonNullองค์ประกอบ

ใช้ได้เมื่อsingletonListไหร่null? เพื่อลบออกnullsจากรายการ นี่คือตัวอย่างหนึ่ง:

List<String> list = Arrays.asList("abc", null, "def", null);
list.removeAll(Collections.singletonList(null));

การใช้ ArrayList . ใหม่

คุณเห็นว่าเราจบลงด้วยรายการที่ว่างเปล่า ใช้ ArrayList ใหม่เมื่อคุณต้องการเปลี่ยนรายการหรือสร้างรายการที่เปลี่ยนแปลงได้จากรายการที่ไม่เปลี่ยนรูป

คอลเลกชัน::unmodifiableList

ใช้Collections::unmodifiableListหรือList::ofเพราะมีพฤติกรรมเหมือนกัน ใช้Collections::unmodifiableListเมื่อคุณต้องการใช้คำฟุ่มเฟือยมากขึ้น

Collections::unmodifiableListสร้างมุมมองที่ไม่สามารถแก้ไขได้ มุมมองที่ไม่สามารถแก้ไขได้คืออะไร? เนื้อหาของรายการสามารถเปลี่ยนแปลงได้ ไม่สามารถเปลี่ยนแปลงรายการได้ การห่อค่าดั้งเดิมทำให้ไม่เปลี่ยนรูป นี่คือตัวอย่างของมุมมองที่ไม่สามารถแก้ไขได้

### TESTING unmodifiableList with mutable content ###
a123

เราได้รับประสบการณ์เช่นเดียวกับCollections::unmodifiableList.

### TESTING listOF with mutable content ###
a123

อย่าทำข้อสรุปเกี่ยวกับความไม่เปลี่ยนรูป คุณสามารถผิด ฉันสรุปผิด และพวกเขาเสียค่าใช้จ่ายชั่วโมงของนักพัฒนา

unmodifiableListหมายความว่าเนื้อหาสามารถเปลี่ยนแปลงได้ คอลเลกชันไม่สามารถ สร้างความแตกต่างและอยู่ห่างจากแมลงที่น่ารำคาญ

singletonListอนุญาตnulls_ เมื่อคุณไม่ต้องการnullsใช้ มีประสิทธิภาพที่แย่กว่า แต่ไม่อนุญาตให้ในไฟล์.List::ofList::ofnullsList

คุณอาจชอบบทความเหล่านี้

9 ตัวอย่าง Java Bad ที่จะทำให้คุณหัวเราะ การ วิเคราะห์ลิงก์ลิสต์ที่นักพัฒนา Java ควรรู้