Hành vi không xác định trong Java

Tôi đã đọc câu hỏi này trên SO , thảo luận về một số hành vi không xác định phổ biến trong C ++ và tôi tự hỏi: Java cũng có hành vi không xác định?

Nếu đó là trường hợp, vậy một số nguyên nhân phổ biến của hành vi không xác định trong Java là gì?

Nếu không, thì các tính năng nào của Java làm cho nó không có các hành vi như vậy và tại sao các phiên bản mới nhất của C và C ++ được triển khai với các thuộc tính này?

Trong Java, bạn có thể xem xét hành vi của chương trình được đồng bộ hóa không chính xác không xác định.

Java 7 JLS sử dụng từ "không xác định" một lần, trong 17.4.8. Yêu cầu thực thi và quan hệ nhân quả :

^{Chúng tôi sử dụng f|dđể biểu thị chức năng nhất định bằng cách hạn chế các lĩnh vực fđể d. Đối với tất cả xtrong d, f|d(x) = f(x)và cho tất cả xkhông trong d, khôngf|d(x) được xác định ...}

Tài liệu API Java chỉ định một số trường hợp khi kết quả không được xác định - ví dụ: trong hàm tạo (không dùng nữa) Ngày (int year, int tháng, int day) :

^{Kết quả là không xác định nếu một đối số nhất định nằm ngoài giới hạn ...}

Javadocs cho trạng thái ExecutorService.invoke ALL (Bộ sưu tập) :

^{Kết quả của phương pháp này không được xác định nếu bộ sưu tập đã cho được sửa đổi trong khi thao tác này đang diễn ra ...}

Ví dụ , loại hành vi "không xác định" ít chính thức hơn có thể được tìm thấy trong ConcurrencyModificationException , trong đó các tài liệu API sử dụng thuật ngữ "nỗ lực tốt nhất":

^{Lưu ý rằng hành vi không nhanh không thể được đảm bảo vì nói chung, không thể thực hiện bất kỳ đảm bảo cứng nào khi có sửa đổi đồng thời không đồng bộ. Hoạt động thất bại nhanh chóng ConcurrentModificationExceptiontrên cơ sở nỗ lực tốt nhất . Do đó, sẽ là sai lầm khi viết một chương trình phụ thuộc vào ngoại lệ này vì tính chính xác của nó ...}

ruột thừa

Một trong những ý kiến câu hỏi đề cập đến một bài viết của Eric Lippert cung cấp phần giới thiệu hữu ích về các vấn đề chủ đề: Hành vi được xác định theo thực hiện .

Tôi đề nghị bài viết này cho lý luận bất khả tri ngôn ngữ, mặc dù đáng lưu ý rằng tác giả nhắm mục tiêu C #, không phải Java.

Theo truyền thống, chúng tôi nói rằng một thành ngữ ngôn ngữ lập trình có hành vi không xác định nếu sử dụng thành ngữ đó có thể có bất kỳ ảnh hưởng nào; nó có thể hoạt động theo cách bạn mong đợi hoặc nó có thể xóa đĩa cứng hoặc làm hỏng máy của bạn. Hơn nữa, tác giả trình biên dịch không có nghĩa vụ cảnh báo bạn về hành vi không xác định. (Và trên thực tế, có một số ngôn ngữ trong đó các chương trình sử dụng thành ngữ "hành vi không xác định" được đặc tả ngôn ngữ cho phép để phá vỡ trình biên dịch!) ...

Ngược lại, một thành ngữ có hành vi được xác định thực hiện là hành vi trong đó tác giả trình biên dịch có một số lựa chọn về cách triển khai tính năng và phải chọn một hành vi. Như tên ngụ ý, hành vi được xác định thực hiện ít nhất là được xác định. Ví dụ, C # cho phép thực hiện ném ngoại lệ hoặc tạo giá trị khi phân chia số nguyên tràn, nhưng việc triển khai phải chọn một ngoại lệ. Nó không thể xóa đĩa cứng của bạn ...

Một số yếu tố dẫn đến một ủy ban thiết kế ngôn ngữ để lại các thành ngữ ngôn ngữ nhất định là hành vi không xác định hoặc xác định thực hiện là gì?

Yếu tố chính đầu tiên là: có hai triển khai ngôn ngữ hiện có trên thị trường không đồng ý về hành vi của một chương trình cụ thể không? ...

Yếu tố chính tiếp theo là: tính năng này có tự nhiên thể hiện nhiều khả năng khác nhau để thực hiện không, một số trong đó rõ ràng tốt hơn các tính năng khác? ...

Một yếu tố thứ ba là: tính năng này phức tạp đến mức việc phân tích chi tiết hành vi chính xác của nó sẽ khó khăn hoặc tốn kém để chỉ định? ...

Một yếu tố thứ tư là: tính năng có đặt ra gánh nặng lớn cho trình biên dịch để phân tích không? ...

Một yếu tố thứ năm là: tính năng có đặt ra gánh nặng cao cho môi trường thời gian chạy không? ...

Một yếu tố thứ sáu là: làm cho hành vi được xác định loại trừ một số tối ưu hóa chính? ...

Đó chỉ là một vài yếu tố xuất hiện trong tâm trí; tất nhiên có nhiều, rất nhiều yếu tố khác mà các ủy ban thiết kế ngôn ngữ tranh luận trước khi thực hiện một tính năng "triển khai được xác định" hoặc "không xác định".

_{Trên đây chỉ là một phạm vi bảo hiểm rất ngắn gọn; bài báo đầy đủ chứa các giải thích và ví dụ cho các điểm được đề cập trong đoạn trích này; nó rất đáng đọc Ví dụ, các chi tiết được đưa ra cho "yếu tố thứ sáu" có thể giúp người ta hiểu rõ hơn về động lực cho nhiều câu lệnh trong Mô hình bộ nhớ Java ( JSR 133 ), giúp hiểu tại sao một số tối ưu hóa được cho phép, dẫn đến hành vi không xác định trong khi các hành vi khác bị cấm, dẫn đến những hạn chế như xảy ra trước và yêu cầu nhân quả .}

_{Không có tài liệu bài viết nào đặc biệt mới đối với tôi nhưng tôi sẽ bị nguyền rủa nếu tôi từng thấy nó được trình bày theo cách thanh lịch, dễ hiểu và dễ hiểu như vậy. Kinh ngạc.}

Ngoài đỉnh đầu, tôi không nghĩ có bất kỳ hành vi không xác định nào trong Java, ít nhất là không có ý nghĩa tương tự như trong C ++.

Lý do cho điều này là có một triết lý khác đằng sau Java so với đằng sau C ++. Mục tiêu thiết kế cốt lõi của Java là cho phép các chương trình chạy không thay đổi trên các nền tảng, do đó, đặc tả kỹ thuật xác định mọi thứ rất rõ ràng.

Ngược lại, mục tiêu thiết kế cốt lõi của C và C ++ là hiệu quả: không nên có bất kỳ tính năng nào (bao gồm tính độc lập nền tảng) mà chi phí hiệu năng ngay cả khi bạn không cần chúng. Cuối cùng, đặc tả này cố tình không xác định một số hành vi vì việc xác định chúng sẽ gây ra việc làm thêm trên một số nền tảng và do đó làm giảm hiệu suất ngay cả đối với những người viết chương trình dành riêng cho một nền tảng và nhận thức được tất cả các đặc điểm riêng của nó.

Thậm chí còn có một ví dụ về việc Java buộc phải đưa ra một cách hạn chế một dạng hành vi không xác định hạn chế vì lý do chính xác đó: từ khóarictfp được giới thiệu trong Java 1.2 để cho phép các phép tính dấu phẩy lệch khỏi chính xác theo tiêu chuẩn IEEE 754 như thông số kỹ thuật đã yêu cầu trước đây , bởi vì làm như vậy đòi hỏi phải làm thêm và làm cho tất cả các phép tính dấu phẩy động chậm hơn trên một số CPU thông thường, trong khi thực sự tạo ra kết quả tồi tệ hơn trong một số trường hợp.

Java cố gắng hết sức để tiêu diệt hành vi không xác định, chính xác là do các bài học của các ngôn ngữ trước đó. Ví dụ, các biến cấp độ lớp được tự động khởi tạo; các biến cục bộ không được tự động khởi tạo vì lý do hiệu suất, nhưng có phân tích luồng dữ liệu phức tạp để ngăn chặn bất kỳ ai viết chương trình có thể phát hiện ra điều này. Tài liệu tham khảo không phải là con trỏ, vì vậy tài liệu tham khảo không hợp lệ không thể tồn tại và hội thảo nullgây ra một ngoại lệ cụ thể.

Tất nhiên vẫn còn một số hành vi không được chỉ định đầy đủ và bạn có thể viết các chương trình không đáng tin cậy nếu bạn cho rằng chúng là như vậy. Chẳng hạn, nếu bạn lặp đi lặp lại so với bình thường (không được sắp xếp) Set, ngôn ngữ đảm bảo rằng bạn sẽ thấy từng phần tử chính xác một lần, nhưng không theo thứ tự bạn sẽ thấy chúng. Thứ tự có thể giống nhau trên các lần chạy liên tiếp hoặc có thể thay đổi; hoặc nó có thể giữ nguyên miễn là không có phân bổ nào khác xảy ra, hoặc miễn là bạn không cập nhật JDK của mình, v.v ... Gần như không thể loại bỏ tất cả các hiệu ứng như vậy; chẳng hạn, bạn sẽ phải đặt hàng rõ ràng hoặc chọn ngẫu nhiên tất cả các hoạt động của Bộ sưu tập và điều đó chỉ đơn giản là không có giá trị bổ sung nhỏ không xác định.

Bạn phải hiểu "Hành vi không xác định" và nguồn gốc của nó.

Hành vi không xác định có nghĩa là một hành vi không được xác định bởi các tiêu chuẩn. C / C ++ có quá nhiều triển khai trình biên dịch khác nhau và các tính năng bổ sung. Các tính năng bổ sung này gắn mã vào trình biên dịch. Điều này là do không có sự phát triển ngôn ngữ tập trung. Vì vậy, một số tính năng nâng cao từ một số trình biên dịch trở thành "hành vi không xác định".

Trong khi đó trong Java, đặc tả ngôn ngữ được kiểm soát bởi Sun-Oracle và không có ai khác cố gắng tạo ra các đặc tả và do đó không có hành vi không xác định.

Chỉnh sửa cụ thể trả lời câu hỏi

1. Java không có các hành vi không xác định vì các tiêu chuẩn được tạo trước các trình biên dịch
2. Các trình biên dịch C / C ++ hiện đại có nhiều / ít tiêu chuẩn hóa các triển khai, nhưng các tính năng được triển khai trước khi tiêu chuẩn hóa vẫn được gắn thẻ là "hành vi không xác định" vì ISO giữ các khía cạnh này.

Java loại bỏ về cơ bản tất cả các hành vi không xác định được tìm thấy trong C / C ++. . hiếm khi gặp phải bởi các lập trình viên.

• Giao diện gốc Java (JNI), một cách để Java gọi mã C hoặc C ++. Có nhiều cách để làm hỏng JNI, như lấy chữ ký hàm sai, thực hiện các cuộc gọi không hợp lệ đến các dịch vụ JVM, làm hỏng bộ nhớ, phân bổ / giải phóng nội dung không chính xác và hơn thế nữa. Tôi đã mắc những lỗi này trước đây và nói chung, toàn bộ JVM gặp sự cố khi bất kỳ một luồng nào thực thi mã JNI đều phạm lỗi.

• Thread.stop(), đó là phản đối. Trích dẫn:

  Tại sao Thread.stopbị phản đối?

  Bởi vì nó vốn không an toàn. Dừng một chuỗi khiến nó mở khóa tất cả các màn hình mà nó đã khóa. (Các màn hình được mở khóa khi ThreadDeathngoại lệ lan truyền ngăn xếp.) Nếu bất kỳ đối tượng nào được bảo vệ trước đây bởi các màn hình này ở trạng thái không nhất quán, các luồng khác có thể xem các đối tượng này ở trạng thái không nhất quán. Những đồ vật như vậy được cho là bị hư hại. Khi các luồng hoạt động trên các đối tượng bị hư hỏng, hành vi tùy ý có thể dẫn đến. Hành vi này có thể tinh tế và khó phát hiện, hoặc nó có thể được phát âm. Không giống như các ngoại lệ không được kiểm soát khác, ThreadDeathgiết chết các chủ đề một cách im lặng; do đó, người dùng không có cảnh báo rằng chương trình của mình có thể bị hỏng. Tham nhũng có thể tự biểu hiện bất cứ lúc nào sau khi thiệt hại thực tế xảy ra, thậm chí là vài giờ hoặc vài ngày trong tương lai.

  https://docs.oracle.com/javase/8/docs/technotes/guides/concurrency/threadPrimitiveDeprecation.html