Tại sao các chuỗi không thể thay đổi trong Java và .NET?

Tại sao họ quyết định làm cho Stringbất biến trong Java và .NET (và một số ngôn ngữ khác)? Tại sao họ không biến nó thành đột biến?

Theo Java hiệu quả , chương 4, trang 73, ấn bản 2:

"Có nhiều lý do chính đáng cho việc này: Các lớp bất biến dễ thiết kế, thực hiện và sử dụng hơn các lớp có thể thay đổi. Chúng ít bị lỗi và an toàn hơn.

[...]

"Các đối tượng bất biến rất đơn giản. Một đối tượng bất biến có thể ở chính xác một trạng thái, trạng thái mà nó được tạo. Nếu bạn chắc chắn rằng tất cả các hàm tạo thiết lập bất biến lớp, thì nó được đảm bảo rằng các bất biến này sẽ luôn đúng với mọi thời gian, với không có nỗ lực từ phía bạn.

[...]

Đối tượng bất biến vốn đã an toàn chủ đề; họ không yêu cầu đồng bộ hóa. Chúng không thể bị hỏng bởi nhiều luồng truy cập đồng thời. Đây là cách tiếp cận dễ dàng nhất để đạt được an toàn luồng. Trong thực tế, không có luồng nào có thể quan sát bất kỳ tác động nào của một luồng khác lên một vật thể bất biến. Do đó, các đối tượng bất biến có thể được chia sẻ tự do

[...]

Các điểm nhỏ khác từ cùng một chương:

Bạn không chỉ có thể chia sẻ các đối tượng bất biến, mà bạn có thể chia sẻ nội bộ của họ.

[...]

Các đối tượng bất biến tạo ra các khối xây dựng tuyệt vời cho các đối tượng khác, cho dù có thể thay đổi hoặc bất biến.

[...]

Nhược điểm thực sự duy nhất của các lớp bất biến là chúng yêu cầu một đối tượng riêng cho mỗi giá trị riêng biệt.

Có ít nhất hai lý do.

Đầu tiên - bảo mật http://www.javafaq.nu/java-article1060.html

Lý do chính khiến String trở nên bất biến là bảo mật. Nhìn vào ví dụ này: Chúng tôi có một phương pháp mở tệp với kiểm tra đăng nhập. Chúng tôi chuyển một Chuỗi cho phương thức này để xử lý xác thực cần thiết trước khi cuộc gọi sẽ được chuyển đến HĐH. Nếu String có thể thay đổi, bằng cách nào đó có thể sửa đổi nội dung của nó sau khi kiểm tra xác thực trước khi HĐH nhận được yêu cầu từ chương trình thì có thể yêu cầu bất kỳ tệp nào. Vì vậy, nếu bạn có quyền mở tệp văn bản trong thư mục người dùng nhưng sau đó, khi bạn bằng cách nào đó thay đổi tên tệp, bạn có thể yêu cầu mở tệp "passwd" hoặc bất kỳ tệp nào khác. Sau đó, một tập tin có thể được sửa đổi và nó sẽ có thể đăng nhập trực tiếp vào hệ điều hành.

Thứ hai - Hiệu quả bộ nhớ http://hikrish.blogspot.com/2006/07/why-opes- class-is-immutable.html

JVM bên trong duy trì "Chuỗi nhóm". Để đạt được hiệu quả bộ nhớ, JVM sẽ tham chiếu đối tượng String từ pool. Nó sẽ không tạo các đối tượng String mới. Vì vậy, bất cứ khi nào bạn tạo một chuỗi ký tự mới, JVM sẽ kiểm tra trong nhóm xem nó đã tồn tại hay chưa. Nếu đã có trong nhóm, chỉ cần đưa tham chiếu đến cùng một đối tượng hoặc tạo đối tượng mới trong nhóm. Sẽ có nhiều tham chiếu trỏ đến cùng các đối tượng String, nếu ai đó thay đổi giá trị, nó sẽ ảnh hưởng đến tất cả các tham chiếu. Vì vậy, mặt trời quyết định làm cho nó bất biến.

Trên thực tế, chuỗi lý do là bất biến trong java không liên quan nhiều đến bảo mật. Hai lý do chính là:

An toàn:

Chuỗi là loại đối tượng được sử dụng rất rộng rãi. Do đó, nó ít nhiều được đảm bảo để được sử dụng trong môi trường đa luồng. Chuỗi là bất biến để đảm bảo rằng an toàn để chia sẻ chuỗi giữa các chuỗi. Có một chuỗi bất biến đảm bảo rằng khi chuyển các chuỗi từ luồng A sang luồng B khác, luồng B không thể sửa đổi chuỗi A của chuỗi một cách bất ngờ.

Điều này không chỉ giúp đơn giản hóa nhiệm vụ vốn đã khá phức tạp của lập trình đa luồng mà còn giúp thực hiện các ứng dụng đa luồng. Truy cập vào các đối tượng có thể thay đổi bằng cách nào đó phải được đồng bộ hóa khi chúng có thể được truy cập từ nhiều luồng, để đảm bảo rằng một luồng không cố đọc giá trị của đối tượng của bạn trong khi nó đang được sửa đổi bởi một luồng khác. Đồng bộ hóa phù hợp vừa khó thực hiện chính xác cho lập trình viên, vừa tốn kém khi chạy. Các đối tượng bất biến không thể được sửa đổi và do đó không cần đồng bộ hóa.

Hiệu suất:

Mặc dù thực tập String đã được đề cập, nó chỉ thể hiện mức tăng nhỏ về hiệu quả bộ nhớ cho các chương trình Java. Chỉ có chuỗi ký tự được thực tập. Điều này có nghĩa là chỉ các chuỗi giống nhau trong mã nguồn của bạn mới chia sẻ cùng một Đối tượng chuỗi. Nếu chương trình của bạn tự động tạo chuỗi giống nhau, chúng sẽ được biểu diễn trong các đối tượng khác nhau.

Quan trọng hơn, chuỗi bất biến cho phép họ chia sẻ dữ liệu nội bộ của họ. Đối với nhiều hoạt động chuỗi, điều này có nghĩa là mảng ký tự bên dưới không cần phải sao chép. Ví dụ: giả sử bạn muốn lấy năm ký tự đầu tiên của Chuỗi. Trong Java, bạn sẽ gọi myString.subopes (0,5). Trong trường hợp này, phương thức chuỗi con () thực hiện chỉ đơn giản là tạo một đối tượng Chuỗi mới chia sẻ char [] cơ bản của myString nhưng ai biết rằng nó bắt đầu ở chỉ số 0 và kết thúc tại chỉ mục 5 của char []. Để đặt cái này ở dạng đồ họa, bạn sẽ kết thúc như sau:

 |               myString                  |
 v                                         v
"The quick brown fox jumps over the lazy dog"   <-- shared char[]
 ^   ^
 |   |  myString.substring(0,5)

Điều này làm cho loại hoạt động này cực kỳ rẻ và O (1) vì hoạt động không phụ thuộc vào độ dài của chuỗi gốc, cũng như độ dài của chuỗi con mà chúng ta cần trích xuất. Hành vi này cũng có một số lợi ích về bộ nhớ, vì nhiều chuỗi có thể chia sẻ char [] bên dưới của chúng.

Chủ đề an toàn và hiệu suất. Nếu một chuỗi không thể được sửa đổi, nó an toàn và nhanh chóng để chuyển một tham chiếu xung quanh giữa nhiều luồng. Nếu các chuỗi có thể thay đổi, bạn sẽ luôn phải sao chép tất cả các byte của chuỗi sang một thể hiện mới hoặc cung cấp đồng bộ hóa. Một ứng dụng thông thường sẽ đọc một chuỗi 100 lần cho mỗi lần chuỗi đó cần được sửa đổi. Xem wikipedia về bất biến .

Người ta thực sự nên hỏi, "tại sao X phải biến đổi?" Tốt hơn hết là mặc định là bất biến, vì những lợi ích đã được đề cập bởi Princess Fluff . Nó nên là một ngoại lệ rằng một cái gì đó có thể thay đổi.

Thật không may, hầu hết các ngôn ngữ lập trình hiện tại đều mặc định là có thể thay đổi, nhưng hy vọng trong tương lai, mặc định sẽ có nhiều tính bất biến hơn (xem Danh sách mong muốn cho Ngôn ngữ lập trình chính tiếp theo ).

Ồ Tôi không thể tin những thông tin sai lệch ở đây. StringS là bất biến không có gì với an ninh. Nếu ai đó đã có quyền truy cập vào các đối tượng trong một ứng dụng đang chạy (điều này sẽ phải được giả định nếu bạn đang cố gắng bảo vệ chống lại ai đó 'hack' a Stringtrong ứng dụng của bạn), họ chắc chắn sẽ có rất nhiều cơ hội khác để hack.

Đó là một ý tưởng khá mới lạ rằng tính bất biến của Stringviệc giải quyết các vấn đề luồng. Hmmm ... Tôi có một đối tượng đang được thay đổi bởi hai luồng khác nhau. Làm thế nào để tôi giải quyết điều này? đồng bộ hóa truy cập vào đối tượng? Naawww ... chúng ta đừng để ai thay đổi đối tượng - điều đó sẽ khắc phục tất cả các vấn đề tương tranh lộn xộn của chúng ta! Trong thực tế, chúng ta hãy làm cho tất cả các đối tượng trở nên bất biến, và sau đó chúng ta có thể loại bỏ sự tương phản được đồng bộ hóa khỏi ngôn ngữ Java.

Lý do thực sự (được chỉ ra bởi những người khác ở trên) là tối ưu hóa bộ nhớ. Nó là khá phổ biến trong bất kỳ ứng dụng cho cùng một chuỗi ký tự được sử dụng nhiều lần. Trên thực tế, nó phổ biến đến mức nhiều thập kỷ trước, nhiều trình biên dịch đã tối ưu hóa việc lưu trữ chỉ một thể hiện duy nhất của một Stringnghĩa đen. Hạn chế của việc tối ưu hóa này là mã thời gian chạy sửa đổi một Stringnghĩa đen giới thiệu một vấn đề bởi vì nó đang sửa đổi thể hiện cho tất cả các mã khác chia sẻ nó. Ví dụ, sẽ không tốt cho một chức năng ở đâu đó trong một ứng dụng để thay đổi Stringnghĩa đen "dog"thành "cat". Một printf("dog")kết quả sẽ "cat"được viết vào thiết bị xuất chuẩn. Vì lý do đó, cần phải có một cách bảo vệ chống lại mã cố gắng thay đổiStringnghĩa đen (nghĩa là làm cho chúng bất biến). Một số trình biên dịch (với sự hỗ trợ từ HĐH) sẽ thực hiện điều này bằng cách đặt Stringchữ vào một phân đoạn bộ nhớ chỉ đọc đặc biệt sẽ gây ra lỗi bộ nhớ nếu thực hiện ghi.

Trong Java, điều này được gọi là thực tập. Trình biên dịch Java ở đây chỉ tuân theo tối ưu hóa bộ nhớ tiêu chuẩn được thực hiện bởi các trình biên dịch trong nhiều thập kỷ. Và để giải quyết vấn đề tương tự của những Stringchữ này được sửa đổi trong thời gian chạy, Java chỉ đơn giản làm cho Stringlớp không thay đổi (tức là, cung cấp cho bạn không có setters nào cho phép bạn thay đổi Stringnội dung). Strings sẽ không phải là bất biến nếu việc thực hiện nghĩa Stringđen không xảy ra.

String không phải là một kiểu nguyên thủy, nhưng bạn thường muốn sử dụng nó với ngữ nghĩa giá trị, tức là giống như một giá trị.

Giá trị là thứ bạn có thể tin tưởng sẽ không thay đổi sau lưng. Nếu bạn viết: String str = someExpr(); Bạn không muốn nó thay đổi trừ khi BẠN làm gì đó với str.

Stringnhư một Objectngữ nghĩa con trỏ tự nhiên, để có được ngữ nghĩa giá trị cũng như nó cần phải bất biến.

Một yếu tố là, nếu Strings là có thể thay đổi, các đối tượng lưu trữ Strings sẽ phải cẩn thận để lưu trữ các bản sao, kẻo thay đổi dữ liệu nội bộ của chúng mà không cần thông báo trước. Cho rằng đó Stringlà một loại khá nguyên thủy như số, thật tuyệt khi người ta có thể coi chúng như thể chúng được truyền theo giá trị, ngay cả khi chúng được truyền bằng tham chiếu (cũng giúp tiết kiệm bộ nhớ).

Tôi biết đây là một vết sưng, nhưng ... Chúng có thực sự bất biến không? Hãy xem xét những điều sau đây.

public static unsafe void MutableReplaceIndex(string s, char c, int i)
{
    fixed (char* ptr = s)
    {
        *((char*)(ptr + i)) = c;
    }
}

...

string s = "abc";
MutableReplaceIndex(s, '1', 0);
MutableReplaceIndex(s, '2', 1);
MutableReplaceIndex(s, '3', 2);
Console.WriteLine(s); // Prints 1 2 3

Bạn thậm chí có thể làm cho nó một phương pháp mở rộng.

public static class Extensions
{
    public static unsafe void MutableReplaceIndex(this string s, char c, int i)
    {
        fixed (char* ptr = s)
        {
            *((char*)(ptr + i)) = c;
        }
    }
}

Điều này làm cho công việc sau đây

s.MutableReplaceIndex('1', 0);
s.MutableReplaceIndex('2', 1);
s.MutableReplaceIndex('3', 2);

Kết luận: Chúng ở trạng thái bất biến được trình biên dịch biết đến. Trong số các điều khoản trên chỉ áp dụng cho các chuỗi .NET vì Java không có con trỏ. Tuy nhiên, một chuỗi có thể hoàn toàn có thể thay đổi bằng cách sử dụng các con trỏ trong C #. Đó không phải là cách con trỏ được sử dụng, sử dụng thực tế hoặc được sử dụng một cách an toàn; tuy nhiên điều đó là có thể, do đó bẻ cong toàn bộ quy tắc "có thể thay đổi". Bạn thường không thể sửa đổi một chỉ mục trực tiếp của một chuỗi và đây là cách duy nhất. Có một cách mà điều này có thể được ngăn chặn bằng cách không cho phép các trường hợp con trỏ của chuỗi hoặc tạo một bản sao khi một chuỗi được trỏ đến, nhưng không được thực hiện, điều đó làm cho các chuỗi trong C # không hoàn toàn bất biến.

Đối với hầu hết các mục đích, một "chuỗi" là (được sử dụng / được coi là / nghĩ về / giả định là) một đơn vị nguyên tử có ý nghĩa , giống như một con số .

Hỏi tại sao các ký tự riêng lẻ của một chuỗi không thể thay đổi do đó giống như hỏi tại sao các bit riêng lẻ của một số nguyên không thể thay đổi.

Bạn nên biết tại sao. Nghĩ về nó đi.

Tôi ghét phải nói điều đó, nhưng thật không may, chúng tôi đang tranh luận điều này bởi vì ngôn ngữ của chúng tôi rất tệ và chúng tôi đang cố gắng sử dụng một từ, chuỗi , để mô tả một khái niệm hoặc lớp đối tượng phức tạp, theo ngữ cảnh.

Chúng tôi thực hiện các tính toán và so sánh với "chuỗi" tương tự như cách chúng tôi làm với các số. Nếu các chuỗi (hoặc số nguyên) có thể thay đổi, chúng ta sẽ phải viết mã đặc biệt để khóa các giá trị của chúng thành các dạng cục bộ bất biến để thực hiện bất kỳ loại tính toán nào một cách đáng tin cậy. Do đó, tốt nhất là nghĩ về một chuỗi như một định danh số, nhưng thay vì dài 16, 32 hoặc 64 bit, nó có thể dài hàng trăm bit.

Khi ai đó nói "chuỗi", tất cả chúng ta đều nghĩ về những điều khác nhau. Những người nghĩ về nó đơn giản chỉ là một tập hợp các nhân vật, không có mục đích cụ thể nào, tất nhiên sẽ kinh hoàng khi ai đó quyết định rằng họ không nên thao túng những nhân vật đó. Nhưng lớp "chuỗi" không chỉ là một mảng các ký tự. Đó là một STRING, không phải a char[]. Có một số giả định cơ bản về khái niệm mà chúng ta gọi là "chuỗi" và nói chung nó có thể được mô tả là đơn vị nguyên tử, có ý nghĩa của dữ liệu được mã hóa như một con số. Khi mọi người nói về "thao tác chuỗi", có lẽ họ thực sự đang nói về việc thao túng các nhân vật để xây dựng chuỗi và StringBuilder là điều tuyệt vời cho điều đó.

Hãy xem xét một lúc nó sẽ như thế nào nếu các chuỗi có thể thay đổi. Hàm API sau đây có thể bị lừa trả lại thông tin cho một người dùng khác nếu chuỗi tên người dùng có thể thay đổi được sửa đổi có chủ ý hoặc vô ý bởi một luồng khác trong khi chức năng này đang sử dụng nó:

string GetPersonalInfo( string username, string password )
{
    string stored_password = DBQuery.GetPasswordFor( username );
    if (password == stored_password)
    {
        //another thread modifies the mutable 'username' string
        return DBQuery.GetPersonalInfoFor( username );
    }
}

Bảo mật không chỉ là về 'kiểm soát truy cập', mà còn về 'an toàn' và 'đảm bảo tính chính xác'. Nếu một phương thức không thể dễ dàng được viết và phụ thuộc để thực hiện một phép tính hoặc so sánh đơn giản một cách đáng tin cậy, thì việc gọi nó là không an toàn, nhưng sẽ an toàn khi tự đặt câu hỏi cho ngôn ngữ lập trình.

Sự bất biến không gắn chặt với an ninh. Đối với điều đó, ít nhất là trong .NET, bạn có được SecureStringlớp.

Chỉnh sửa sau: Trong Java bạn sẽ tìm thấy GuardedString, một triển khai tương tự.

Quyết định có chuỗi đột biến trong C ++ gây ra rất nhiều vấn đề, hãy xem bài viết xuất sắc này của Kelvin Henney về Bệnh Mad COW .

COW = Sao chép khi viết.

Đó là một sự đánh đổi. Strings đi vào nhóm Stringvà khi bạn tạo nhiều Strings giống nhau , chúng có chung bộ nhớ. Các nhà thiết kế cho rằng kỹ thuật tiết kiệm bộ nhớ này sẽ hoạt động tốt trong trường hợp phổ biến, vì các chương trình có xu hướng nghiền trên cùng một chuỗi rất nhiều.

Nhược điểm là việc ghép nối tạo ra rất nhiều Strings chỉ chuyển tiếp và trở thành rác, thực sự gây hại cho hiệu năng bộ nhớ. Bạn có StringBuffervà StringBuilder(trong Java, StringBuildercũng ở .NET) để sử dụng để bảo toàn bộ nhớ trong những trường hợp này.

Strings trong Java không thực sự bất biến, bạn có thể thay đổi giá trị của chúng bằng cách sử dụng sự phản chiếu và tải lớp. Bạn không nên phụ thuộc vào tài sản đó để bảo mật. Ví dụ xem: Magic Trick In Java

Bất biến là tốt. Xem Java hiệu quả. Nếu bạn phải sao chép Chuỗi mỗi lần bạn chuyển nó, thì đó sẽ là rất nhiều mã dễ bị lỗi. Bạn cũng có sự nhầm lẫn về việc sửa đổi nào ảnh hưởng đến tham chiếu nào. Theo cùng một cách mà Integer phải bất biến để hành xử như int, String phải hành xử như bất biến để hành động như người nguyên thủy. Trong C ++, việc chuyển các chuỗi theo giá trị thực hiện điều này mà không đề cập rõ ràng trong mã nguồn.

Có một ngoại lệ cho gần như mọi quy tắc:

using System;
using System.Runtime.InteropServices;

namespace Guess
{
    class Program
    {
        static void Main(string[] args)
        {
            const string str = "ABC";

            Console.WriteLine(str);
            Console.WriteLine(str.GetHashCode());

            var handle = GCHandle.Alloc(str, GCHandleType.Pinned);

            try
            {
                Marshal.WriteInt16(handle.AddrOfPinnedObject(), 4, 'Z');

                Console.WriteLine(str);
                Console.WriteLine(str.GetHashCode());
            }
            finally
            {
                handle.Free();
            }
        }
    }
}

Phần lớn là vì lý do bảo mật. Việc bảo mật một hệ thống sẽ khó hơn nhiều nếu bạn không thể tin tưởng rằng hệ thống của mình Stringchống giả.