Tại sao Java 8 không bao gồm các bộ sưu tập bất biến?

Nhóm Java đã thực hiện rất nhiều công việc tuyệt vời để loại bỏ các rào cản đối với lập trình chức năng trong Java 8. Đặc biệt, các thay đổi đối với Bộ sưu tập java.util thực hiện rất tốt việc chuyển đổi các chuỗi thành các hoạt động truyền phát rất nhanh. Xem xét công việc họ đã thực hiện tốt như thế nào khi thêm các hàm hạng nhất và phương thức chức năng vào các bộ sưu tập, tại sao họ hoàn toàn thất bại trong việc cung cấp các bộ sưu tập bất biến hoặc thậm chí các giao diện bộ sưu tập bất biến?

Không thay đổi bất kỳ mã hiện có nào, nhóm Java bất cứ lúc nào cũng có thể thêm các giao diện bất biến giống như các giao diện có thể thay đổi, trừ các phương thức "thiết lập" và làm cho các giao diện hiện có mở rộng từ chúng, như sau:

                  ImmutableIterable
     ____________/       |
    /                    |
Iterable        ImmutableCollection
   |    _______/    /          \   \___________
   |   /           /            \              \
 Collection  ImmutableList  ImmutableSet  ImmutableMap  ...
    \  \  \_________|______________|__________   |
     \  \___________|____________  |          \  |
      \___________  |            \ |           \ |
                  List            Set           Map ...

Chắc chắn, các hoạt động như List.add () và Map.put () hiện trả về giá trị boolean hoặc trước đó cho khóa đã cho để cho biết thao tác thành công hay thất bại. Các bộ sưu tập bất biến sẽ phải xử lý các phương thức như các nhà máy và trả lại một bộ sưu tập mới có chứa phần tử được thêm vào - không tương thích với chữ ký hiện tại. Nhưng điều đó có thể được giải quyết bằng cách sử dụng một tên phương thức khác như ImmutableList.append () hoặc .addAt () và ImmutableMap.putEntry (). Độ dài kết quả sẽ lớn hơn nhiều so với lợi ích của việc làm việc với các bộ sưu tập không thay đổi và hệ thống loại sẽ ngăn các lỗi gọi phương thức sai. Theo thời gian, các phương pháp cũ có thể bị phản đối.

Thắng các bộ sưu tập bất biến:

• Đơn giản - lý luận về mã đơn giản hơn khi dữ liệu cơ bản không thay đổi.
• Tài liệu - nếu một phương thức có giao diện bộ sưu tập bất biến, bạn biết rằng nó sẽ không sửa đổi bộ sưu tập đó. Nếu một phương thức trả về một bộ sưu tập bất biến, bạn biết bạn không thể sửa đổi nó.
• Đồng thời - bộ sưu tập bất biến có thể được chia sẻ an toàn trên các chủ đề.

Là một người đã nếm trải các ngôn ngữ giả định sự bất biến, rất khó để quay trở lại miền Tây hoang dã của sự đột biến tràn lan. Các bộ sưu tập của Clojure (trừu tượng hóa chuỗi) đã có mọi thứ mà các bộ sưu tập Java 8 cung cấp, cộng với tính không thay đổi (mặc dù có thể sử dụng thêm bộ nhớ và thời gian do danh sách liên kết được đồng bộ hóa thay vì các luồng). Scala có cả bộ sưu tập có thể thay đổi và bất biến với một bộ đầy đủ các thao tác và mặc dù các thao tác đó rất háo hức, việc gọi .iterator đưa ra một cái nhìn lười biếng (và có nhiều cách khác để đánh giá chúng một cách lười biếng). Tôi không thấy Java có thể tiếp tục cạnh tranh như thế nào nếu không có các bộ sưu tập bất biến.

Ai đó có thể chỉ cho tôi lịch sử hoặc thảo luận về điều này? Chắc chắn nó ở nơi nào đó.

Bởi vì bộ sưu tập bất biến hoàn toàn yêu cầu chia sẻ để có thể sử dụng. Mặt khác, mọi hoạt động đơn lẻ sẽ thả cả một danh sách khác vào đống ở đâu đó. Các ngôn ngữ hoàn toàn bất biến, như Haskell, tạo ra lượng rác đáng kinh ngạc mà không cần tối ưu hóa và chia sẻ mạnh mẽ. Có bộ sưu tập chỉ sử dụng được với <50 yếu tố không đáng để đưa vào thư viện chuẩn.

Hơn nữa, các bộ sưu tập bất biến thường có những triển khai khác nhau về cơ bản so với các đối tác có thể thay đổi của chúng. Ví dụ ArrayList, xem xét một bất biến hiệu quả ArrayListsẽ không phải là một mảng! Nó nên được thực hiện với một cây cân bằng với hệ số phân nhánh lớn, Clojure sử dụng 32 IIRC. Làm cho các bộ sưu tập có thể thay đổi là "bất biến" bằng cách thêm một bản cập nhật chức năng là một lỗi hiệu năng cũng giống như rò rỉ bộ nhớ.

Hơn nữa, việc chia sẻ không khả thi trong Java. Java cung cấp quá nhiều móc nối không giới hạn đối với tính biến đổi và tính công bằng tham chiếu để chia sẻ "chỉ là một tối ưu hóa". Có thể bạn sẽ khó chịu một chút nếu bạn có thể sửa đổi một yếu tố trong danh sách và nhận ra bạn vừa sửa đổi một yếu tố trong 20 phiên bản khác của danh sách đó bạn có.

Điều này cũng loại trừ các lớp lớn tối ưu hóa rất quan trọng cho tính bất biến hiệu quả, chia sẻ, hợp nhất luồng, bạn đặt tên cho nó, khả năng biến đổi phá vỡ nó. (Điều đó sẽ tạo ra một khẩu hiệu tốt cho các nhà truyền giáo FP)

Một bộ sưu tập có thể thay đổi không phải là một kiểu con của một bộ sưu tập bất biến. Thay vào đó, các bộ sưu tập có thể thay đổi và bất biến là anh em ruột của các bộ sưu tập có thể đọc được. Thật không may, các khái niệm "chỉ đọc", "chỉ đọc" và "không thay đổi" dường như bị làm mờ cùng nhau, mặc dù chúng có nghĩa là ba điều khác nhau.

• Một lớp cơ sở bộ sưu tập hoặc loại giao diện có thể đọc được hứa hẹn rằng người ta có thể đọc các mục và không cung cấp bất kỳ phương tiện trực tiếp nào để sửa đổi bộ sưu tập, nhưng không đảm bảo rằng mã nhận được tham chiếu không thể truyền hoặc thao tác theo cách cho phép sửa đổi.

• Giao diện bộ sưu tập chỉ đọc không bao gồm bất kỳ thành viên mới nào, nhưng chỉ nên được triển khai bởi một lớp hứa hẹn rằng không có cách nào để thao tác tham chiếu đến nó theo cách làm thay đổi bộ sưu tập cũng như không nhận được tham chiếu đến thứ gì đó điều đó có thể làm như vậy Tuy nhiên, điều đó không hứa hẹn rằng bộ sưu tập sẽ không được sửa đổi bởi một thứ khác có liên quan đến nội bộ. Lưu ý rằng giao diện bộ sưu tập chỉ đọc có thể không thể ngăn chặn việc thực hiện bởi các lớp có thể thay đổi, nhưng có thể chỉ định rằng bất kỳ triển khai hoặc lớp nào có nguồn gốc từ một triển khai, cho phép đột biến sẽ được coi là triển khai "bất hợp pháp" hoặc phái sinh của việc triển khai .

• Một bộ sưu tập bất biến là một bộ sưu tập sẽ luôn giữ cùng một dữ liệu miễn là có bất kỳ tham chiếu nào đến nó. Bất kỳ việc thực hiện giao diện bất biến nào không phải lúc nào cũng trả lại cùng một dữ liệu để đáp ứng với một yêu cầu cụ thể đã bị hỏng.

Đó là đôi khi hữu ích để có loại mạnh mẽ liên quan có thể thay đổi và không thể thay đổi bộ sưu tập mà cả hai thực hiện hoặc xuất phát từ cùng loại "dễ đọc", và có loại có thể đọc được bao gồm AsImmutable, AsMutablevà AsNewMutablephương pháp. Thiết kế như vậy có thể cho phép mã muốn duy trì dữ liệu trong bộ sưu tập để gọi AsImmutable; phương pháp đó sẽ tạo một bản sao phòng thủ nếu bộ sưu tập có thể thay đổi, nhưng bỏ qua bản sao nếu nó không thay đổi.

Khung công tác bộ sưu tập Java cung cấp khả năng tạo một phiên bản chỉ đọc của một bộ sưu tập bằng sáu phương thức tĩnh trong lớp java.util.Collections :

• unmodifiableCollection (Bộ sưu tập c)
• unmodifiableList (Danh sách danh sách)
• unmodifiableMap (Bản đồ m)
• không thể thay đổi (Set s)
• unmodifiableSorticMap (SortedMap m)
• unmodifiableSortset (Sắp xếp s)

Như ai đó đã chỉ ra trong các nhận xét cho câu hỏi ban đầu, các bộ sưu tập được trả về có thể không được coi là bất biến vì mặc dù các bộ sưu tập không thể được sửa đổi (không có thành viên nào có thể được thêm hoặc xóa khỏi bộ sưu tập đó), các đối tượng thực tế được tham chiếu bởi bộ sưu tập có thể được sửa đổi nếu loại đối tượng của họ cho phép nó.

Tuy nhiên, vấn đề này sẽ vẫn tồn tại bất kể mã trả về một đối tượng hay bộ sưu tập đối tượng không thể thay đổi. Nếu loại cho phép các đối tượng của nó bị đột biến, thì quyết định đó được đưa ra trong thiết kế của loại và tôi không thấy sự thay đổi đối với JCF có thể thay đổi điều đó như thế nào. Nếu bất biến là quan trọng, thì các thành viên của một bộ sưu tập nên thuộc loại bất biến.

Đây là một câu hỏi rất hay. Tôi thích giải trí với ý tưởng rằng tất cả các mã được viết bằng java và chạy trên hàng triệu máy tính trên toàn thế giới, mỗi ngày, xung quanh đồng hồ, khoảng một nửa tổng số chu kỳ đồng hồ phải bị lãng phí không làm gì ngoài việc tạo ra các bản sao an toàn của các bộ sưu tập được trả về bởi các chức năng. (Và thu gom rác các bộ sưu tập này một phần nghìn giây sau khi tạo.)

Một tỷ lệ lập trình viên java nhận thức được sự tồn tại của unmodifiableCollection()họ các phương thức của Collectionslớp, nhưng ngay cả trong số họ, nhiều người không bận tâm đến nó.

Và tôi không thể đổ lỗi cho họ: một giao diện giả vờ đọc-ghi nhưng sẽ ném UnsupportedOperationExceptionnếu bạn phạm sai lầm khi gọi bất kỳ phương thức 'viết' nào của nó là một điều khá xấu xa!

Bây giờ, một giao diện giống như Collectionmà sẽ được thiếu add(), remove()và clear()phương pháp này sẽ không phải là một "ImmutableCollection" giao diện; nó sẽ là một giao diện "UnmodifiableCollection". Như một vấn đề thực tế, không bao giờ có thể có giao diện "ImmutableCollection", bởi vì tính bất biến là bản chất của việc triển khai, không phải là một đặc điểm của giao diện. Tôi biết, điều đó không rõ ràng lắm; hãy để tôi giải thích.

Giả sử ai đó trao cho bạn một giao diện bộ sưu tập chỉ đọc như vậy; Có an toàn để chuyển nó sang một chủ đề khác? Nếu bạn biết chắc chắn rằng nó đại diện cho một bộ sưu tập thực sự bất biến, thì câu trả lời sẽ là "có"; thật không may, vì nó là một giao diện, bạn không biết nó được triển khai như thế nào, vì vậy câu trả lời phải là không : đối với tất cả những gì bạn biết, nó có thể là một quan điểm không thể thay đổi (đối với bạn) về một bộ sưu tập thực tế có thể thay đổi được, (giống như những gì bạn nhận được với Collections.unmodifiableCollection(),) vì vậy cố gắng đọc từ nó trong khi một luồng khác đang sửa đổi nó sẽ dẫn đến việc đọc dữ liệu bị hỏng.

Vì vậy, những gì bạn đã mô tả về cơ bản là một tập hợp các giao diện bộ sưu tập "Không thể thay đổi", nhưng "Không thể thay đổi". Điều quan trọng là phải hiểu rằng "Không thể thay đổi" đơn giản có nghĩa là bất kỳ ai có tham chiếu đến giao diện như vậy đều bị ngăn không cho sửa đổi bộ sưu tập cơ bản và chúng bị ngăn chặn đơn giản vì giao diện thiếu bất kỳ phương pháp sửa đổi nào, không phải vì bộ sưu tập cơ bản nhất thiết là bất biến. Bộ sưu tập cơ bản rất có thể là đột biến; bạn không có kiến ​​thức về, và không kiểm soát được điều đó.

Để có những bộ sưu tập bất biến, chúng sẽ phải là các lớp chứ không phải giao diện!

Các lớp bộ sưu tập bất biến này sẽ phải là cuối cùng, do đó, khi bạn được cung cấp một tham chiếu đến một bộ sưu tập như vậy, bạn biết chắc rằng nó sẽ hoạt động như một bộ sưu tập bất biến cho dù bạn hay bất kỳ ai có liên quan đến nó, có thể làm với nó

Vì vậy, để có một bộ sưu tập hoàn chỉnh trong java, (hoặc bất kỳ ngôn ngữ mệnh lệnh khai báo nào khác), chúng ta sẽ cần những điều sau đây:

1. Một tập hợp các giao diện bộ sưu tập không thể thay đổi .

2. Một tập hợp các giao diện bộ sưu tập có thể thay đổi , mở rộng những giao diện không thể thay đổi.

3. Một tập hợp các lớp bộ sưu tập có thể thay đổi thực hiện các giao diện có thể thay đổi và bằng cách mở rộng cũng là các giao diện không thể thay đổi.

4. Một tập hợp các lớp bộ sưu tập bất biến , thực hiện các giao diện không thể thay đổi, nhưng chủ yếu được truyền qua dưới dạng các lớp, để đảm bảo tính bất biến.

Tôi đã thực hiện tất cả những điều trên cho vui, và tôi đang sử dụng chúng trong các dự án, và chúng hoạt động như một cơ duyên.

Lý do tại sao chúng không phải là một phần của thời gian chạy java có lẽ là vì người ta nghĩ rằng điều này sẽ quá nhiều / quá phức tạp / quá khó hiểu.

Cá nhân, tôi nghĩ rằng những gì tôi mô tả ở trên thậm chí không đủ; một điều nữa dường như là cần thiết là một tập hợp các giao diện & lớp có thể thay đổi cho tính bất biến cấu trúc . (Điều này có thể đơn giản được gọi là "Cứng nhắc" vì tiền tố "StructaturalImmutable" quá dài.)

Các bộ sưu tập bất biến có thể được đệ quy sâu, so với nhau, và không hiệu quả một cách vô lý nếu sự bình đẳng đối tượng là bởi safeHash. Đây được gọi là rừng merkle. Nó có thể là trên mỗi bộ sưu tập hoặc trong các phần của chúng như cây AVL (tự cân bằng nhị phân) cho bản đồ được sắp xếp.

Trừ khi tất cả các đối tượng java trong các bộ sưu tập này có id duy nhất hoặc một số chuỗi bit để băm, bộ sưu tập không có gì để băm để đặt tên duy nhất.

Ví dụ: Trên máy tính xách tay 4x1.6ghz của tôi, tôi có thể chạy 200K sha256s mỗi giây với kích thước nhỏ nhất phù hợp với 1 chu kỳ băm (tối đa 55 byte), so với op op 500K hoặc op op 3M trong một hàm băm dài. 200K / log (bộ sưu tập Kích thước) bộ sưu tập mới mỗi giây đủ nhanh cho một số điều trong đó tính toàn vẹn dữ liệu và khả năng mở rộng toàn cầu ẩn danh là quan trọng.

Hiệu suất. Bộ sưu tập theo bản chất của họ có thể rất lớn. Sao chép 1000 phần tử sang một cấu trúc mới với 1001 phần tử thay vì chèn một phần tử chỉ đơn giản là khủng khiếp.

Đồng thời. Nếu bạn có một số luồng đang chạy, họ có thể muốn có phiên bản hiện tại của bộ sưu tập chứ không phải phiên bản đã được thông qua 12 giờ trước khi chuỗi bắt đầu.

Lưu trữ. Với các đối tượng bất biến trong môi trường đa luồng, bạn có thể kết thúc với hàng chục bản sao của đối tượng "giống nhau" tại các điểm khác nhau trong vòng đời của nó. Không quan trọng đối với Lịch hoặc đối tượng Ngày nhưng khi bộ sưu tập 10.000 tiện ích này sẽ giết bạn.