Tuần tự hóa Java - ưu điểm và nhược điểm, sử dụng hay tránh? [đóng cửa]

Tuần tự hóa được sử dụng để duy trì trong Java. Có thể ổn khi duy trì một vài đối tượng sử dụng tuần tự hóa. Nhưng, đối với một số lượng lớn các đối tượng, ORM, Cơ sở dữ liệu, vv có thể tốt hơn. Có vẻ như tuần tự hóa chỉ hữu ích cho các công việc nhỏ. Có lẽ tôi đã sai lầm. Vì vậy, xin vui lòng cho tôi biết những lợi thế của tuần tự hóa so với các phương pháp không tuần tự hóa là gì? Khi nào nên sử dụng và khi nào nên tránh?

Câu hỏi này xuất hiện trong đầu tôi sau khi xem bài viết của DZone Is Object serialization Evil?

Và đây là những dòng dẫn đến câu hỏi của tôi:

Nếu bạn nhìn vào Java và các đối tượng phiên của nó, tuần tự hóa đối tượng thuần túy được sử dụng. Giả sử rằng một phiên ứng dụng khá ngắn, có nghĩa là nhiều nhất là vài giờ, việc tuần tự hóa đối tượng là đơn giản, được hỗ trợ tốt và được xây dựng trong khái niệm Java của phiên. Tuy nhiên, khi sự tồn tại của dữ liệu kéo dài trong một khoảng thời gian dài hơn, có thể là vài ngày hoặc vài tuần và bạn phải lo lắng về các bản phát hành mới của ứng dụng, việc tuần tự hóa nhanh chóng trở thành xấu xa. Như bất kỳ nhà phát triển Java giỏi nào cũng biết, nếu bạn có kế hoạch tuần tự hóa một đối tượng, ngay cả trong một phiên, bạn cần một ID tuần tự hóa thực sự (serialVersionUID), không chỉ là 1L và bạn cần triển khai giao diện Nối tiếp. Tuy nhiên, hầu hết các nhà phát triển không biết các quy tắc thực sự đằng sau quá trình khử lưu huỳnh Java. Nếu đối tượng của bạn đã thay đổi, không chỉ thêm các trường đơn giản vào đối tượng, có thể Java không thể giải tuần tự hóa đối tượng một cách chính xác ngay cả khi ID tuần tự hóa không thay đổi. Đột nhiên, bạn không thể truy xuất dữ liệu của mình nữa, điều này vốn đã xấu.

Bây giờ, có thể các nhà phát triển đọc điều này có thể nói rằng họ sẽ không bao giờ viết mã có vấn đề này. Điều đó có thể đúng, nhưng còn một thư viện mà bạn sử dụng hoặc một số nhà phát triển khác không còn được sử dụng bởi công ty của bạn thì sao? Bạn có thể đảm bảo rằng vấn đề này sẽ không bao giờ xảy ra? Cách duy nhất để đảm bảo đó là sử dụng một phương thức tuần tự hóa khác.

Tuần tự hóa chủ yếu được sử dụng trong hai lĩnh vực:

• nguyên mẫu của sự bền bỉ

  hầu như mọi đồ thị đối tượng đều có thể nhanh chóng được tạo ra tuần tự hóa, để chứng minh nhanh chóng các khái niệm hoặc các ứng dụng nhanh và bẩn, điều này có thể nhanh hơn việc thiết lập một lớp ORM thực hoặc hệ thống kiên trì khác

• lưu trữ ngắn hạn của các đối tượng gần như tùy ý:

  Ví dụ, các máy chủ ứng dụng có xu hướng duy trì thông tin phiên sử dụng tuần tự hóa. Điều này có lợi thế là các giá trị trong phiên có thể là hầu hết mọi loại (miễn là nó được tuần tự hóa).

Đối với hầu hết các mục đích sử dụng khác, nhược điểm mà bạn (và bài viết) đề cập là quá lớn: định dạng chính xác khó giữ ổn định, thay đổi lớp có thể dễ dàng làm cho dữ liệu tuần tự của bạn không thể đọc được, đọc / ghi dữ liệu bằng mã không phải là Java không thể (hoặc ít nhất là khó hơn rất nhiều so với cần thiết).

JAXB và các công nghệ tương tự cung cấp các chức năng tương tự với chi phí thấp tương tự, trong khi giảm một số vấn đề.

Tôi sử dụng tuần tự hóa đối tượng để cho phép phân tích sau khi chết trong trường hợp có lỗi không mong muốn trong sản xuất. Các đầu vào cho một phép tính được tuần tự hóa thành một tệp dữ liệu. Nếu một lỗi được báo cáo, một chương trình đơn giản có thể tải lại các đầu vào và chạy lại phép tính với trình gỡ lỗi được đính kèm. Hoặc một vỏ Groovy có thể được sử dụng để tải lại các đối tượng và sửa đổi chúng nếu muốn.

Chúng tôi cũng sử dụng tuần tự hóa để truyền các đối tượng Java thông qua HTTP đến một dịch vụ web. Dễ dàng hơn nhiều so với việc xê-ri hóa đến và từ văn bản. Nhược điểm là cài đặt máy khách và máy chủ phải được triển khai cùng nhau, nhưng đó không phải là vấn đề vì chúng tôi kiểm soát cả hai đầu.

Những lợi thế của tuần tự hóa so với các phương pháp không tuần tự hóa là gì?

Tuần tự hóa Java có một số lợi thế:

• Được tích hợp vào hệ thống : Bạn không cần phải dựa vào các công cụ, thư viện hoặc cấu hình của bên thứ ba.

• Tương đối đơn giản để hiểu , ít nhất là vào đầu.

• Mọi nhà phát triển đều biết điều đó (hoặc nên). Bất kể các nhà phát triển Java chấp thuận hay không chấp thuận, họ có thể quen thuộc với việc tuần tự hóa các đối tượng Java.

Và, tất nhiên, có những nhược điểm:

• Lưu lượng dòng chảy Java tiêu chuẩn. Phân bổ bộ nhớ nhưng không gọi hàm tạo, vì vậy các trường tạm thời không được khởi tạo. Các trường được khởi tạo theo thứ tự bảng chữ cái, không phải thứ tự nguồn.

• Không quá hiệu quả về mặt không gian, nhưng cũng không kinh khủng. Bạn có thể muốn nén kết quả.

• Giòn trừ khi bạn có biện pháp phòng ngừa khi đối tượng của bạn thay đổi. Và thậm chí sau đó.

Khi nào nên sử dụng và khi nào nên tránh?

Sử dụng khi :

• Vấn đề quy mô triển khai. Được xây dựng trong hệ thống, vì vậy 0 byte thêm.

• Tất cả các diễn viên sẽ sử dụng các phiên bản tương thích.

• Lưu trữ lâu dài không phải là một vấn đề.

Tránh khi :

• Bất kỳ điều nào ở trên không áp dụng.

Tuần tự hóa và ORM / cơ sở dữ liệu là những thứ khác nhau, mặc dù có một số trùng lặp.

Một đối tượng được tuần tự hóa đại diện cho tất cả các thông tin cần thiết để "làm tan băng" một đối tượng bền bỉ và phục hồi dữ liệu của nó. Một ORM và cơ sở dữ liệu lưu dữ liệu vào cơ sở dữ liệu. Một lớp có thể có các trường thông tin không được lưu trữ trong cơ sở dữ liệu bởi ORM, ví dụ như trường được tính toán.

Ngoài ra, tuần tự hóa và ORM đang giải quyết các vấn đề khác nhau. Tuần tự hóa giải quyết vấn đề duy trì biểu đồ đối tượng cho một luồng (bộ nhớ, hệ thống tệp, v.v.). Một ORM xử lý việc ánh xạ các mẩu thông tin vào các cột cơ sở dữ liệu và truy xuất và khởi tạo các đối tượng, ngoài việc cung cấp các tính năng như tìm kiếm và tải chậm.

Sử dụng ORM khi bạn muốn duy trì dữ liệu vào cơ sở dữ liệu cho các tình huống bạn đang xử lý một lượng lớn dữ liệu hoặc cần báo cáo, tìm kiếm / truy vấn, lưu kho hoặc những thứ khác mà cơ sở dữ liệu giỏi. Sử dụng tuần tự hóa khi bạn muốn lưu một đại diện của (các) cấu trúc dữ liệu của bạn vào đĩa.

Tuần tự hóa hiếm khi được sử dụng trong thực tế.

Như đã đề cập, trường hợp sử dụng phổ biến nhất để tuần tự hóa là lưu trữ các đối tượng dưới dạng các đốm màu trong cơ sở dữ liệu phiên. Điều này hoạt động tốt vì hai lý do: các phiên có xu hướng ngắn và cơ sở dữ liệu phiên làm thế nào không có kiến ​​thức về cách ánh xạ các đối tượng tùy ý vào một mô hình quan hệ.

Đối với dữ liệu cần được lưu giữ trong thời gian dài (như giỏ hàng của Amazon), cách tốt nhất là lưu trữ dữ liệu đó trong cơ sở dữ liệu.

Cơ chế duy trì phiên làm việc đảm bảo rằng người dùng có phiên hoạt động được trả về cùng một máy chủ. Cơ sở dữ liệu phiên chỉ được truy cập khi máy chủ bị lỗi và người dùng được chuyển hướng đến một máy chủ mới. Máy chủ mới phát hiện một phiên hoạt động, nhưng không tìm thấy nó trong bộ nhớ, vì vậy nó cố gắng truy xuất nó từ cơ sở dữ liệu phiên nhằm cố gắng cung cấp trải nghiệm liền mạch cho người dùng.

Có hai vấn đề với cách tiếp cận này:

Đầu tiên, xóa dữ liệu phiên vào cơ sở dữ liệu phiên là một quá trình chậm. Việc xóa dữ liệu phiên quá thường làm giảm hiệu suất và hầu hết các máy chủ được định cấu hình để xóa mỗi 30 giây hoặc mỗi phút hoặc lâu hơn. Giải pháp chuyển đổi dự phòng "dường như" này không bao giờ hiệu quả 100%.

Thứ hai, kinh nghiệm của tôi là hầu hết các khách hàng đồng ý rằng việc đưa ra một thông báo lỗi yêu cầu người dùng đăng nhập và thử lại trong các trường hợp hiếm hoi mà máy chủ bị lỗi. Trong trường hợp này, chúng tôi tắt hoàn toàn cơ sở dữ liệu phiên và tận hưởng hiệu suất tăng.

Một cách sử dụng tuần tự hóa khác là cung cấp thời gian phản hồi nhanh hơn bằng cách sử dụng các khung như Flex sử dụng tuần tự hóa và nén biểu đồ đối tượng cho các tương tác giữa máy chủ và máy khách.

Như những người khác đã chỉ ra, có một số lý do sáng tạo và hữu ích để sử dụng tuần tự hóa, nhưng đây là những lý do hiếm gặp trong thực tế.

Lịch sử tuần tự hóa rất khó để thực hiện chính xác và độ tin cậy, hạn chế sử dụng nó trong một số ít trường hợp. Hầu hết các nhà phát triển sẽ không bao giờ tự sắp xếp các đối tượng, nhưng có thể dựa vào các khung làm việc đằng sau hậu trường.

Câu trả lời ngắn gọn cho "khi nào nên sử dụng tuần tự hóa Java" và "khi nào cần tránh tuần tự hóa Java"

Sử dụng tuần tự hóa Java nếu

• cần ít mã hóa
• không có vấn đề gì khi dữ liệu nhị phân không thể đọc được
• tìm kiếm trong dữ liệu tuần tự không cần thiết (không thể truy vấn giống như cơ sở dữ liệu)
• hoặc
  • cấu trúc dữ liệu tuần tự không thay đổi hoặc
  • sẽ không thành vấn đề nếu dữ liệu tuần tự được lưu trữ không thể đọc được sau khi "thay đổi cấu trúc dữ liệu" nữa (tức là dữ liệu phiên trong ứng dụng web)

Trong tất cả các tình huống khác, "Tuần tự hóa nhị phân Java" là xấu

Lựa chọn thay thế

• xml nối tiếp
• cơ sở dữ liệu nosql
• cơ sở dữ liệu quan hệ với ORM