JavaRush /จาวาบล็อก /Random-TH /ตั้งแต่ 8 ถึง 13: ภาพรวมทั้งหมดของเวอร์ชัน Java ส่วนที่ 2...
Константин
ระดับ

ตั้งแต่ 8 ถึง 13: ภาพรวมทั้งหมดของเวอร์ชัน Java ส่วนที่ 2

เผยแพร่ในกลุ่ม
บทความนี้เป็นส่วนที่สองของการทบทวนนวัตกรรมใน Java เวอร์ชัน 8-13 ส่วนแรกอยู่ที่นี่ โดยไม่ต้องกังวลใจอีกต่อไป เรามาต่อกันต่อ: จนถึงวันที่ 25 กันยายน 2018 เมื่อ JDK ใหม่เปิดตัว:

ชวา 11

ตั้งแต่ 8 ถึง 13: ภาพรวมทั้งหมดของเวอร์ชัน Java  ส่วนที่ 2 - 1

var (ในแลมบ์ดา)

จากนี้ไป เราสามารถระบุประเภทของพารามิเตอร์ lambda หรือละเว้นได้เมื่อเขียนนิพจน์ lambda (นิพจน์ lambda ที่พิมพ์โดยปริยาย):
Function<String, String> append = (var string) -> string + " Text";
String appendedString = append.apply("Some");
System.out.println(appendedString);
คุณยังสามารถเพิ่มคำอธิบายประกอบให้กับพารามิเตอร์ lambda ได้โดยไม่ต้องเขียนชื่อประเภทตัวแปรแบบเต็ม:
Function<String, String> append = (@NonNull var string) -> string + " Text";

ซี(ZGC)

ZGC เป็นตัวรวบรวมขยะตัวใหม่ที่ใช้งานไม่ได้ มันจัดสรรหน่วยความจำใหม่แต่ไม่เคยรีสตาร์ท ZGC สัญญาว่าจะจัดการหน่วยความจำจำนวนมากด้วยปริมาณงานที่สูงและเวลาแฝงต่ำ (ZGC ใช้ได้เฉพาะบนแพลตฟอร์ม 64 บิตเท่านั้น) การระบายสีอ้างอิง - ZGC ใช้พอยน์เตอร์ 64 บิตด้วยเทคนิคที่เรียกว่าการระบายสีพอยน์เตอร์ พอยน์เตอร์สีเก็บข้อมูลเพิ่มเติมเกี่ยวกับออบเจ็กต์บนฮีป เมื่อหน่วยความจำกระจัดกระจาย สิ่งนี้จะช่วยหลีกเลี่ยงการลดประสิทธิภาพลงเมื่อ GC ต้องการหาพื้นที่สำหรับการจัดสรรใหม่ การรวบรวมขยะโดยใช้ ZGC ประกอบด้วยขั้นตอนต่อไปนี้:
  1. หยุดโลก: เรามองหาจุดเริ่มต้นเพื่อเข้าถึงวัตถุบนฮีป (เช่น ตัวแปรในเครื่องหรือฟิลด์คงที่)
  2. จุดตัดของกราฟวัตถุโดยเริ่มจากลิงก์รูท เราทำเครื่องหมายแต่ละวัตถุที่เราไปถึง (ZGC เดินผ่านกราฟวัตถุและตรวจสอบเครื่องหมายสี ทำเครื่องหมายวัตถุที่มีอยู่)
  3. การจัดการกับ Edge Case บางอย่าง เช่น ลิงก์ที่อ่อนแอ
  4. การเคลื่อนย้ายวัตถุที่มีชีวิต จะทำให้ฮีปมีพื้นที่ขนาดใหญ่ว่างเพื่อเร่งการจัดสรร
  5. เมื่อระยะการย้ายเริ่มต้นขึ้น ZGC จะแบ่งฮีปออกเป็นหน้าต่างๆ และทำงานทีละหน้า
  6. ZGC เสร็จสิ้นการเคลื่อนไหวของรากใดๆ และการเคลื่อนไหวที่เหลือจะเกิดขึ้น
หัวข้อนี้ซับซ้อนและสับสนมาก การอภิปรายโดยละเอียดจะต้องมีบทความแยกต่างหาก ดังนั้นฉันจะทิ้งไว้ที่นี่:

เอปซิลอน จีซี

Epsilon เป็นตัวรวบรวมขยะที่จัดการการจัดสรรหน่วยความจำ แต่ไม่ได้ใช้กลไกการกู้คืนหน่วยความจำจริง เมื่อฮีป Java ที่มีอยู่หมดลง JVM จะปิดตัวลง นั่นคือ หากคุณเริ่มสร้างออบเจ็กต์ในอาเรย์ที่ไม่มีที่สิ้นสุดโดยไม่ผูกกับการอ้างอิงกับตัวรวบรวมขยะนี้ แอปพลิเคชันจะขัดข้องด้วยOutOfMemoryError (และหากเกิดกับสิ่งอื่นใด จะไม่มีผล เนื่องจากมันจะล้างวัตถุโดยไม่มีการอ้างอิง) . เหตุใดจึงจำเป็น? นี่คือเหตุผล:
  1. การทดสอบประสิทธิภาพ
  2. การทดสอบความดันหน่วยความจำ
  3. การทดสอบอินเทอร์เฟซ VM
  4. งานสั้นมาก.
  5. การปรับปรุงเวลาแฝงที่ลดลงครั้งสุดท้าย
  6. การปรับปรุงปริมาณงานลดลงครั้งล่าสุด
ลิงค์ที่เป็นประโยชน์: นวัตกรรมอื่นๆ:
  1. ByteArrayOutputStreamมีวิธีการvoid writeBytes(byte [])ที่เขียนไบต์ทั้งหมดจากอาร์กิวเมนต์ไปOutputStreamที่
  2. FileReaderและFileWriterมีคอนสตรัคเตอร์ใหม่ที่ให้คุณระบุ Charset ได้
  3. Pathคว้าสองวิธีใหม่ โดยof(String, String [])ส่งคืนPathเส้นทางหรือลำดับของสตริงจากอาร์กิวเมนต์สตริงที่เมื่อรวมกันเป็นสตริงเส้นทางและof(URI): ส่งคืน Path จาก URI
  4. Pattern— ได้รับวิธีasMatchPredicate()การตรวจสอบว่าสตริงอินพุตที่กำหนดตรงกับรูปแบบที่กำหนดหรือไม่ (ไม่ว่าจะอนุญาตให้คุณสร้างเพรดิเคตโดยใช้นิพจน์ทั่วไปหรือไม่ เพื่อให้คุณสามารถกรองข้อมูลในสตรีมได้)
  5. Stringฉันเลือกวิธีการที่เป็นประโยชน์มากมาย เช่น:
    • String strip(): จะส่งคืนสตริงที่เป็นสตริงนี้ให้เรา โดยลบช่องว่างทั้งหมดที่จุดเริ่มต้นและจุดสิ้นสุดของสตริงออก (คล้ายกับการตัดแต่ง () แต่กำหนดช่องว่างต่างกัน)
    • String stripLeading(): จะส่งคืนสตริงที่เป็นสตริงนี้ให้เรา โดยลบช่องว่างนำหน้าออกจากสตริง
    • String stripTrailing(): จะส่งคืนสตริงที่เป็นสตริงนี้ให้เรา โดยลบช่องว่างที่ส่วนท้ายของสตริง
    • Stream lines(): จะคืนค่าเราStreamจากStringแยกออกจากสตริงนี้ คั่นด้วยตัวคั่นบรรทัด
    • String repeat(int): จะส่งคืนสตริงที่ต่อกันของสตริงนี้ให้เรา ซึ่งทำซ้ำหลายครั้ง
    • boolean isBlank(): จะคืนค่าเป็นจริงหากสตริงว่างเปล่าหรือมีเพียงช่องว่าง มิฉะนั้นจะเป็นเท็จ
  6. Thread— วิธีการ destroy() และ stop(Throwable) ถูกลบออกไปแล้ว
  7. Filesมีวิธีการใหม่ๆ มากมาย:
    • String readString(Path): อ่านข้อมูลทั้งหมดจากไฟล์ลงในสตริง ในขณะที่ถอดรหัสจากไบต์เป็นอักขระโดยใช้การเข้ารหัส UTF-8
    • String readString(Path, Charset): เช่นเดียวกับในวิธีการข้างต้น โดยมีความแตกต่างที่การถอดรหัสจากไบต์เป็นอักขระเกิดขึ้นโดยใช้ Charset ที่ระบุ
    • Path writeString (Path, CharSequence, OpenOption []): เขียนลำดับอักขระลงในไฟล์ อักขระถูกเข้ารหัสเป็นไบต์โดยใช้การเข้ารหัส UTF-8
    • Path writeString(Path, CharSequence,Charset, OpenOption []): วิธีการเดียวกับข้างต้น เฉพาะอักขระเท่านั้นที่ถูกเข้ารหัสเป็นไบต์โดยใช้การเข้ารหัสที่ระบุใน Charset
นี่เป็นนวัตกรรม API ที่น่าสนใจที่สุด (ในความเห็นของฉัน) ต่อไปนี้เป็นเนื้อหาบางส่วนสำหรับการตรวจสอบโดยละเอียดเพิ่มเติม:

ชวา 12

หกเดือนผ่านไปและเราได้เห็นวิวัฒนาการขั้นต่อไปของ Java ถึงเวลาที่จะหยิบพลั่วความรู้ออกมาแล้วขุด ตั้งแต่ 8 ถึง 13: ภาพรวมทั้งหมดของเวอร์ชัน Java  ส่วนที่ 2 - 2

อัพเดต G1

มีการปรับปรุงต่อไปนี้สำหรับ G1:
  1. เรียกคืนหน่วยความจำที่จัดสรรที่ไม่ได้ใช้

    ในหน่วยความจำฮีป Java มีหน่วยความจำที่ไม่ได้ใช้ (หรืออีกนัยหนึ่งคือไม่ได้ใช้งาน) ใน Java 12 พวกเขาตัดสินใจแก้ไขปัญหานี้ตอนนี้:

    • G1 ส่งคืนหน่วยความจำจากฮีปใน GC แบบเต็มหรือระหว่างการวนซ้ำแบบขนาน G1 พยายามป้องกัน GC เต็มรูปแบบและเริ่มการวนซ้ำแบบขนานตามการจัดสรรฮีป เราจะต้องบังคับให้ G1 คืนหน่วยความจำจากฮีป

    การปรับปรุงนี้มุ่งเน้นไปที่ประสิทธิภาพโดยการส่งคืนหน่วยความจำจากฮีปไปยังระบบปฏิบัติการโดยอัตโนมัติเมื่อไม่ได้ใช้งาน G1

  2. การยกเลิกคอลเลกชันแบบผสมเมื่อเกินเวลาหยุดชั่วคราว

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

ไมโครเบนช์มาร์ก

Java 12 เปิดตัวการทดสอบ microbenchmarking เพื่อให้สามารถทดสอบประสิทธิภาพของ JVM ได้อย่างง่ายดายโดยใช้การวัดประสิทธิภาพที่มีอยู่ สิ่งนี้จะมีประโยชน์มากสำหรับใครก็ตามที่ต้องการทำงานกับ JVM เอง การทดสอบเพิ่มเติมถูกสร้างขึ้นโดยใช้ Java Microbenchmark Harness (JMH) การทดสอบเหล่านี้ช่วยให้สามารถทดสอบประสิทธิภาพได้อย่างต่อเนื่องบน JVM JEP 230 เสนอการทดสอบประมาณ 100 รายการ โดยมีการทดสอบใหม่เมื่อมีการเปิดตัว Java เวอร์ชันใหม่ นี่คือตัวอย่างการทดสอบที่เพิ่มเข้ามา

เชนันโดอาห์

นี่คืออัลกอริธึมการรวบรวมขยะ (GC) ที่มีจุดมุ่งหมายเพื่อรับประกันเวลาตอบสนองต่ำ (ขีดจำกัดล่างคือ 10-500 ms) ซึ่งจะช่วยลดเวลาหยุดชั่วคราวของ GC เมื่อทำงานล้างข้อมูลไปพร้อมๆ กับการรันเธรด Java ใน Shenandoah เวลาหยุดชั่วคราวไม่ขึ้นอยู่กับขนาดฮีป ซึ่งหมายความว่าเวลาหยุดชั่วคราวจะเท่ากันไม่ว่าฮีปของคุณจะมีขนาดเท่าใดก็ตาม นี่เป็นฟีเจอร์ทดลองและไม่รวมอยู่ในบิลด์มาตรฐาน (Oracle) ของ OpenJDK

ปรับปรุงสวิตช์

Java 12 ได้ปรับปรุงนิพจน์สวิตช์สำหรับการจับคู่รูปแบบ มีการแนะนำไวยากรณ์ใหม่ L → นี่คือรายการประเด็นสำคัญของสวิตช์ใหม่ :
  1. ไวยากรณ์ใหม่ช่วยลดความจำเป็นในการใช้คำสั่งแบ่งเพื่อป้องกันข้อผิดพลาด
  2. การสลับนิพจน์ไม่ล้มเหลวอีกต่อไป
  3. นอกจากนี้ เราสามารถกำหนดค่าคงที่ได้หลายค่าในป้ายกำกับเดียว
  4. ตอนนี้จำเป็นต้องใช้ตัวพิมพ์เริ่มต้นในนิพจน์สวิตช์
  5. ตัวแบ่งใช้ในนิพจน์ Switch เพื่อส่งคืนค่าจากรีจิสเตอร์เอง (อันที่จริงสวิตช์สามารถส่งคืนค่าได้)
ลองดูตัวอย่างนี้:
var result = switch (someDay) {
  case "M", "W", "F" -> "MWF";
  case "T", "TH", "S" -> "TTS";
  default -> {
      if(someDay.isEmpty())
            break "Please insert a valid day.";
      else
            break "Looks like a Sunday.";
  }
};
คำแนะนำขั้นสุดท้ายในการสลับนิพจน์ใน Java 13 คุณสมบัติใหม่อื่น ๆ :
  1. String:

    transform(Function f)- ใช้ฟังก์ชันที่ให้มากับสตริง ผลลัพธ์อาจไม่ใช่สตริง
    indent(int x)— เพิ่มช่องว่าง x ให้กับสตริง หากพารามิเตอร์เป็นลบ จำนวนช่องว่างนำหน้าจำนวนนี้จะถูกลบออก (ถ้าเป็นไปได้)

  2. Files- คว้าวิธีการเช่นmismatch()ซึ่งในทางกลับกันจะค้นหาและส่งกลับตำแหน่งของไบต์แรกที่ไม่ตรงกันในเนื้อหาของสองไฟล์หรือ -1L หากไม่มีที่ไม่ตรงกัน

  3. มีคลาสใหม่ปรากฏขึ้น -CompactNumberFormatสำหรับการจัดรูปแบบเลขทศนิยมในรูปแบบกะทัดรัด ตัวอย่างของรูปแบบย่อนี้คือ 1M แทนที่จะเป็น 1,000,000 ดังนั้นจึงต้องใช้เพียงสองตัวสองตัวแทนที่จะเป็นอักขระเก้าตัว

  4. นอกจากนี้ยังมีอันใหม่ enumซึ่งNumberFormatStyleมีสองค่า - LONG และ SHORT

  5. InputStream มีวิธีการ skipNBytes(long n) : ข้ามจำนวนไบต์ที่ n จากสตรีมอินพุต

ลิงค์ Java 12 ที่น่าสนใจ:

ชวา 13

โลกไม่หยุดนิ่ง มันเคลื่อนไหว พัฒนา เช่นเดียวกับ Java - Java 13 ตั้งแต่ 8 ถึง 13: ภาพรวมทั้งหมดของเวอร์ชัน Java  ส่วนที่ 2 - 3

บล็อกข้อความ

Java ประสบปัญหาเล็กน้อยเสมอเมื่อพูดถึงการกำหนดสตริง หากเราจำเป็นต้องกำหนดบรรทัดด้วยการเว้นวรรค การแบ่งบรรทัด เครื่องหมายคำพูดหรืออย่างอื่น สิ่งนี้ทำให้เกิดปัญหาบางประการ ดังนั้นเราจึงต้องใช้อักขระพิเศษ: ตัวอย่างเช่น \n สำหรับการขึ้นบรรทัดใหม่ หรือหลีกบางส่วนของบรรทัด ตัวมันเอง ซึ่งจะช่วยลดความสามารถในการอ่านโค้ดลงอย่างมาก และใช้เวลาเพิ่มเติมในการเขียนบรรทัดดังกล่าว สิ่งนี้จะสังเกตเห็นได้ชัดเจนเป็นพิเศษเมื่อเขียนสตริงที่แสดง JSON, XML, HTML ฯลฯ ดังนั้นหากเราต้องการเขียน Json ขนาดเล็ก มันจะมีลักษณะดังนี้:
String JSON_STRING = "{\r\n" + "\"name\" : \"someName\",\r\n" + "\"site\" : \"https://www.someSite.com/\"\r\n" + "}";
จากนั้น Java 13 ก็เข้ามามีบทบาทและเสนอวิธีแก้ปัญหาให้เราในรูปแบบของเครื่องหมายคำพูดคู่สามเท่าก่อนและหลังข้อความ (ซึ่งเรียกว่าบล็อกข้อความ) ลองดูตัวอย่าง json ก่อนหน้านี้โดยใช้นวัตกรรมนี้:
String TEXT_BLOCK_JSON = """
{
    "name" : "someName",
    "site" : "https://www.someSite.com/"
}
""";
ง่ายกว่าและชัดเจนกว่ามากใช่ไหม? มี การเพิ่ม Stringวิธีการใหม่สามวิธี ตามลำดับสำหรับการจัดการบล็อกเหล่านี้:
  • stripIndent(): ลบช่องว่างแบบสุ่มออกจากสตริง สิ่งนี้มีประโยชน์หากคุณกำลังอ่านสตริงหลายบรรทัดและต้องการใช้การแยกช่องว่างแบบสุ่มแบบเดียวกับที่เกิดขึ้นกับการประกาศอย่างชัดเจน (โดยพื้นฐานแล้วเป็นการจำลองคอมไพเลอร์เพื่อลบช่องว่างแบบสุ่ม)
  • formatted(Object... args ): คล้ายกับformat(String format, Object... arg)แต่สำหรับบล็อกข้อความ
  • translateEscapes(): ส่งกลับสตริงที่มีลำดับหลีก (เช่น \r) แปลเป็นค่า Unicode ที่สอดคล้องกัน

ปรับปรุงสวิตช์

นิพจน์สวิตช์ถูกนำมาใช้ใน Java 12 และ 13 ได้ทำการปรับปรุง ใน 12 คุณกำหนดค่าที่ส่งคืนโดยใช้ตัวแบ่ง ใน 13 ค่าที่ส่งคืนถูกแทนที่ด้วยผลผลิต ตอนนี้นิพจน์สวิตช์ที่เรามีในส่วน Java 12 สามารถเขียนใหม่เป็น:
var result = switch (someDay) {
  case "M", "W", "F" -> "MWF";
  case "T", "TH", "S" -> "TTS";
  default -> {
      if(someDay.isEmpty())
          yield "Please insert a valid day.";
      else
          yield "Looks like a Sunday.";
  }
};
แม้ว่าจะเป็นเรื่องปกติสำหรับพวกเราที่โปรแกรมเมอร์คุ้นเคยกับ Java อยู่แล้วที่จะยอมรับการหยุดทำงาน แต่มันก็ค่อนข้างแปลก อะไรคือความแตกจริงที่พยายามจะบอกฉัน? คำหลักผลตอบแทนใหม่ (ค่อนข้างใหม่) มีความชัดเจนยิ่งขึ้นและอาจปรากฏในที่อื่น ๆ ในอนาคตที่มีการส่งคืนค่า สำหรับผู้ที่สนใจหัวข้อนี้อย่างลึกซึ้ง ฉันขอแนะนำให้คุณทำความคุ้นเคยกับเนื้อหาเหล่านี้:

คลังเก็บ CDS แบบไดนามิก

CDS - การแบ่งปันข้อมูลในชั้นเรียน ช่วยให้คุณสามารถจัดแพคเกจชุดของคลาสที่ใช้กันทั่วไปลงในไฟล์เก็บถาวรที่สามารถโหลดได้ในภายหลังโดยอินสแตนซ์ JVM หลายรายการ ทำไมเราถึงต้องการสิ่งนี้? ความจริงก็คือในกระบวนการโหลดคลาส JVM ดำเนินการค่อนข้างมากในการดำเนินการที่ใช้ทรัพยากรมาก เช่น การอ่านคลาส การจัดเก็บไว้ในโครงสร้างภายใน การตรวจสอบความถูกต้องของคลาสการอ่าน การค้นหาและการโหลดคลาสที่ขึ้นต่อกัน ฯลฯ . และหลังจากทั้งหมดนี้ชั้นเรียนก็พร้อมที่จะทำงาน เป็นที่เข้าใจได้ว่ามีการใช้ทรัพยากรจำนวนมากโดยเปล่าประโยชน์ เนื่องจากอินสแตนซ์ JVM มักจะสามารถโหลดคลาสเดียวกันได้ ตัวอย่างเช่น String, LinckedList, Integer หรือคลาสของแอปพลิเคชันเดียวกันและทั้งหมดนี้คือทรัพยากร หากเราดำเนินการขั้นตอนที่จำเป็นทั้งหมดเพียงครั้งเดียวแล้ววางคลาสที่ออกแบบใหม่ไว้ในไฟล์เก็บถาวรที่สามารถโหลดลงในหน่วยความจำของ JVM หลายรายการได้ สิ่งนี้จะช่วยประหยัดพื้นที่หน่วยความจำได้อย่างมากและลดเวลาการเริ่มต้นแอปพลิเคชัน จริงๆ แล้ว CDS ทำให้สามารถสร้างไฟล์เก็บถาวรดังกล่าวได้ Java 9 อนุญาตให้เพิ่มคลาสของระบบลงในไฟล์เก็บถาวรเท่านั้น Java 10 - รวมคลาสแอปพลิเคชันไว้ในไฟล์เก็บถาวร การสร้างไฟล์เก็บถาวรดังกล่าวประกอบด้วย:
  • การสร้างรายการคลาสที่โหลดโดยแอปพลิเคชัน
  • สร้างไฟล์เก็บถาวรที่จำเป็นมากด้วยคลาสที่เราพบ
นวัตกรรมใน Java 13 ปรับปรุง CDS เพื่อให้สามารถสร้างไฟล์เก็บถาวรเมื่อแอปพลิเคชันยุติลง ซึ่งหมายความว่าทั้งสองขั้นตอนข้างต้นจะรวมกันเป็นหนึ่งเดียว และจุดสำคัญอีกประการหนึ่ง: เฉพาะคลาสที่โหลดในขณะที่แอปพลิเคชันกำลังทำงานอยู่เท่านั้นที่จะถูกเพิ่มลงในไฟล์เก็บถาวร กล่าวอีกนัยหนึ่ง คลาสเหล่านั้นที่ยังคงอยู่ใน application.jar แต่ไม่ได้โหลดด้วยเหตุผลบางประการ จะไม่ถูกเพิ่มไปยังไฟล์เก็บถาวร

อัปเดตซ็อกเก็ต API

Socket API ( java.net.Socket และ java.net.ServerSocket ) เป็นส่วนสำคัญของ Java นับตั้งแต่เริ่มก่อตั้ง แต่ซ็อกเก็ตไม่เคยได้รับการอัปเดตในช่วงยี่สิบปีที่ผ่านมา เขียนด้วยภาษา C และ Java มีขนาดใหญ่มากและดูแลรักษายาก แต่ Java 13 ตัดสินใจที่จะทำการปรับเปลี่ยนของตัวเองในเรื่องทั้งหมดนี้และแทนที่การใช้งานพื้นฐาน ตอนนี้ แทนที่จะเป็นPlainSocketImpl อินเทอร์เฟซ ของผู้ให้บริการจะถูกแทนที่ด้วยNioSocketImpl การใช้งานโค้ดใหม่นี้ใช้โครงสร้างพื้นฐานแบ็กเอนด์เดียวกันกับjava.nio โดยพื้นฐานแล้ว คลาสใช้แคชบัฟเฟอร์ java.util.concurrent และกลไกการล็อค (ซึ่งอิงตามเซ็กเมนต์) แทนที่จะใช้วิธีการซิงโครไนซ์ ไม่ต้องใช้โค้ดเนทีฟอีกต่อไป ทำให้ง่ายต่อการพอร์ตไปยังแพลตฟอร์มต่างๆ ถึงกระนั้น เราก็มีวิธีที่จะกลับไปใช้PlainSocketImplได้ แต่จากนี้ไปNioSocketImpl จะถูกใช้เป็นค่าเริ่ม ต้น

การส่งคืนหน่วยความจำสำหรับ ZGC

ดังที่เราจำได้ว่าตัวรวบรวมขยะ Zเปิดตัวใน Java 11 เพื่อเป็นกลไกการรวบรวมขยะที่มีความหน่วงต่ำ เพื่อให้ GC หยุดชั่วคราวไม่เกิน 10 ms แต่ในขณะเดียวกัน ก็ไม่เหมือนกับ GC HotSpot เสมือนอื่นๆ เช่น Shenandoah และ G1 ตรงที่สามารถคืนหน่วยความจำไดนามิกที่ไม่ได้ใช้ไปยังระบบปฏิบัติการได้ การปรับเปลี่ยนนี้จะเพิ่มความสามารถ J นี้ให้กับ ZGC ดังนั้นเราจึงได้รับพื้นที่หน่วยความจำที่ลดลงพร้อมกับประสิทธิภาพที่ดีขึ้น และตอนนี้ ZGC จะส่งคืนหน่วยความจำที่ไม่มีข้อผูกมัดไปยังระบบปฏิบัติการตามค่าเริ่มต้นจนกว่าจะถึงขนาดฮีปขั้นต่ำที่ระบุ อีกประการหนึ่ง: ตอนนี้ ZGC มีขนาดฮีปที่รองรับสูงสุดที่ 16 TB ก่อนหน้านี้ 4TB ถือเป็นขีดจำกัด นวัตกรรมอื่นๆ:
  1. javax.security- เพิ่มคุณสมบัติjdk.sasl.disabledMechanismsเพื่อปิดการใช้งานกลไก SASL
  2. java.nio- เพิ่มวิธีการแล้วFileSystems.newFileSystem (Path, Map <String,?>)- ตามลำดับสำหรับการสร้างไฟล์ใหม่
  3. ตอนนี้ คลาสjava.nioมีวิธีการแบบสัมบูรณ์ (ตรงข้ามกับแบบสัมพัทธ์) getและset- เช่นเดียวกับคลาสนามธรรมพื้นฐานBufferที่รวมวิธีslice()การดึงข้อมูลส่วนหนึ่งของบัฟเฟอร์
  4. เพิ่มjavax.xml.parsersวิธีการสำหรับการสร้างอินสแตนซ์ของโรงงาน DOM และ SAX (พร้อมการรองรับเนมสเปซ)
  5. การสนับสนุน Unicode ได้รับการอัพเดตเป็นเวอร์ชัน 12.1
ลิงค์ที่น่าสนใจบน Java 13:

ผลลัพธ์

เราสามารถดูนวัตกรรมที่ประกาศใน Java 14 ได้ แต่เนื่องจากมันจะได้เห็นแสงสว่างในเร็วๆ นี้ - JDK 14 มีกำหนดเปิดตัวในวันที่ 17 มีนาคม 2020 จึงเป็นการดีที่สุดที่จะดำเนินการตรวจสอบแยกต่างหากและครบถ้วนทันทีหลังจากเปิดตัว . ฉันอยากจะดึงความสนใจของคุณไปที่ความจริงที่ว่าในภาษาการเขียนโปรแกรมอื่น ๆ ที่มีช่วงพักยาวระหว่างรีลีสเช่น Python 2–3 นั้นไม่มีความเข้ากันได้นั่นคือหากโค้ดเขียนด้วย Python 2 คุณจะ ต้องทำงานหนักในการแปลเป็น 3 Java มีความพิเศษในเรื่องนี้เพราะว่ามันเข้ากันได้แบบย้อนหลังอย่างยิ่ง ซึ่งหมายความว่าโปรแกรม Java 5 หรือ 8 ของคุณรับประกันว่าจะทำงานบนเครื่องเสมือน Java 8-13 โดยมีข้อยกเว้นบางประการที่คุณไม่จำเป็นต้องกังวลในตอนนี้ เห็นได้ชัดว่าวิธีนี้ใช้ไม่ได้ผล: ตัวอย่างเช่น หากแอปพลิเคชันของคุณใช้ฟังก์ชัน Java 13 ที่ไม่มีอยู่ใน Java 8 JVM นั่นคือทั้งหมดที่ฉันมีสำหรับวันนี้ ขอแสดงความนับถือผู้ที่อ่านมาถึงจุดนี้)) ตั้งแต่ 8 ถึง 13: ภาพรวมทั้งหมดของเวอร์ชัน Java  ส่วนที่ 2 - 5
ความคิดเห็น
TO VIEW ALL COMMENTS OR TO MAKE A COMMENT,
GO TO FULL VERSION