Viết Java có độ trễ thấp [đã đóng]


30

Có bất kỳ kỹ thuật dành riêng cho Java nào (những thứ không áp dụng cho C ++) để viết mã có độ trễ thấp, trong Java không? Tôi thường thấy các vai trò độ trễ thấp của Java và họ yêu cầu kinh nghiệm viết Java có độ trễ thấp - đôi khi có vẻ hơi oxymoron.

Suy nghĩ duy nhất tôi có thể nghĩ đến là trải nghiệm với JNI, thuê ngoài các cuộc gọi I / O đến mã gốc. Cũng có thể sử dụng mô hình người gây rối, nhưng đó không phải là một công nghệ thực tế.

Có bất kỳ mẹo cụ thể nào về Java để viết mã độ trễ thấp không?

Tôi biết rằng có một Spec Java thời gian thực, nhưng tôi đã được cảnh báo thời gian thực không giống như độ trễ thấp ....


đừng tạo ra quá nhiều đối tượng có thể kích hoạt chu kỳ thu thập sẽ là phỏng đoán của tôi
ratchet freak

@ratchet, tôi đoán mọi thứ liên quan đến Mạng hoặc Đĩa cũng sẽ là JNI?
user997112

Đối với liên kết hơn nữa và các bài thuyết trình, bạn có thể quan tâm đến các tài khoản của Performance Java Nhóm plus.google.com/u/1/communities/107178245817384004088
Peter Lawrey

Tôi sẽ thêm bằng sun.misc.Unsafe, trực tiếp hoặc gián tiếp là hữu ích. Nhiều phương pháp Không an toàn được coi là nội tại, có nghĩa là chúng được thay thế bằng mã máy, giúp tránh mọi JNI.
Peter Lawrey

Kỹ thuật chính là tránh hoàn toàn bất kỳ chi phí nào. Bạn có thể đọc thêm về điều đó trong bài viết này Phát triển Java mà không cần GC
rdalmeida 29/07/2015

Câu trả lời:


35

Ngoài ý kiến ​​của Martijn, tôi muốn thêm:

  1. Làm nóng JVM của bạn. Bytecode bắt đầu được giải thích cho Hotspot và sau đó được biên dịch trên máy chủ sau 10K quan sát . Biên dịch theo tầng có thể là một khoảng cách dừng tốt.

  2. Classloading là một quá trình tuần tự liên quan đến IO vào đĩa. Đảm bảo rằng tất cả các lớp cho luồng giao dịch chính của bạn được tải trước và chúng không bao giờ bị đuổi khỏi thế hệ perm.

  3. Thực hiện theo " Nguyên tắc người viết đơn " để tránh sự tranh chấp và tác động xếp hàng của Luật Little, cộng với nghiên cứu Luật của Amdhal cho những gì có thể song song và nó có đáng không.

  4. Mô hình hóa miền doanh nghiệp của bạn và đảm bảo tất cả các thuật toán của bạn là O (1) hoặc ít nhất là O (log n). Đây có lẽ là nguyên nhân lớn nhất của vấn đề hiệu suất trong kinh nghiệm của tôi. Hãy chắc chắn rằng bạn có các bài kiểm tra hiệu suất để bao gồm các trường hợp chính.

  5. Độ trễ thấp trong Java không chỉ giới hạn ở Java. Bạn cần hiểu toàn bộ ngăn xếp mà mã của bạn đang thực thi. Điều này sẽ liên quan đến điều chỉnh hệ điều hành, chọn phần cứng phù hợp, điều chỉnh phần mềm hệ thống và trình điều khiển thiết bị cho phần cứng đó.

  6. Hãy thực tế. Nếu bạn cần độ trễ thấp, đừng chạy trên máy ảo hóa. Đảm bảo bạn có đủ lõi cho tất cả các luồng cần ở trạng thái có thể chạy được.

  7. Bỏ lỡ bộ nhớ cache là chi phí lớn nhất của bạn để hiệu suất. Sử dụng các thuật toán thân thiện với bộ đệm và đặt mối quan hệ với các lõi của bộ xử lý với tasket hoặc numactl cho JVM hoặc JNI cho các luồng riêng lẻ.

  8. Hãy xem xét một JVM thay thế như Zing từ Azul với trình thu gom rác tạm dừng.

  9. Quan trọng nhất là có được một người tham gia với kinh nghiệm. Điều này sẽ giúp bạn tiết kiệm rất nhiều thời gian trong thời gian dài. Ổ cắm không biết xấu hổ :-)

Thời gian thực và độ trễ thấp là các đối tượng riêng biệt mặc dù thường liên quan. Thời gian thực là về dự đoán nhiều hơn là nhanh. Theo kinh nghiệm của tôi, các JVM thời gian thực, ngay cả các JVM thời gian thực mềm, đều chậm hơn các JVM thông thường.


2
+1 cho một câu trả lời tuyệt vời. Là một người có hứng thú với các bài đăng xử lý tx như thế này là một điểm khởi đầu tuyệt vời cho nghiên cứu.
mcfinnigan

23

Có một loạt những điều cần nhận thức là có. Hiện tại tôi đang ở đảo Crete với quyền truy cập mạng hạn chế nên việc này sẽ khá ngắn. Ngoài ra, tôi không phải là một chuyên gia có độ trễ thấp, nhưng một số đồng nghiệp của tôi chơi một trong cuộc sống thực :-).

  1. Bạn cần đánh giá cao sự đồng cảm cơ học (một thuật ngữ được đặt ra bởi Martin Thompson ). Nói cách khác, bạn cần hiểu phần cứng cơ bản của bạn đang làm gì. Biết được CPU tải các dòng bộ đệm như thế nào, băng thông đọc / ghi của chúng là bao nhiêu, tốc độ của bộ nhớ chính và nhiều, nhiều hơn nữa là rất quan trọng. Tại sao? Bởi vì bạn sẽ cần lý do làm thế nào mã nguồn Java của bạn ảnh hưởng đến Hệ điều hành / Phần cứng thông qua JVM thời gian chạy. Ví dụ: là cách các biến trường của bạn được trình bày trong mã nguồn của bạn gây ra sự trục xuất dòng bộ đệm (chi phí cho bạn ~ 150 chu kỳ đồng hồ), hmmm ... :-).

  2. Nói chung, bạn muốn khóa thuật toán miễn phí và I / O. Ngay cả ứng dụng đồng thời được thiết kế tốt nhất (sử dụng khóa) cũng có nguy cơ bị chặn, việc chặn trong độ trễ thấp thường rất tệ :-).

  3. Hiểu phân bổ đối tượng và thu gom rác. Đây là một chủ đề lớn, nhưng về cơ bản, bạn muốn tránh tạm dừng GC (thường gây ra bởi bản chất Dừng thế giới của các bộ sưu tập GC khác nhau). Trong nhiều trường hợp, các nhà sưu tập chuyên gia như nhà sưu tập Azul có thể giải quyết vấn đề này cho bạn, nhưng đối với hầu hết mọi người, họ cần hiểu cách điều chỉnh các Sun / Oracle GC (CMS, G1, v.v.).

  4. Hotspot JIT là tuyệt vời đáng kinh ngạc. Tìm hiểu về tối ưu hóa của nó, nhưng nói chung tất cả các kỹ thuật OO tốt (đóng gói, phương pháp nhỏ, càng nhiều dữ liệu bất biến càng tốt) sẽ cho phép JIT tối ưu hóa, cung cấp cho bạn các mức hiệu suất mà mã C / C ++ tạo ra tốt cho bạn.

  5. Kiến trúc hệ thống tổng thể. Lưu ý về mạng, cách các máy được đặt cùng vị trí, nếu bạn được kết nối với trao đổi qua cáp, v.v.

  6. Hãy nhận biết tác động của việc đăng nhập. ghi nhật ký nhị phân hoặc sử dụng đầu ra được mã hóa mà bạn có thể phân tích cú pháp có lẽ là một ý tưởng tốt.

Nhìn chung, tôi thực sự khuyên bạn nên tham gia khóa học Điều chỉnh hiệu suất Java của Kirk Pepperdine [Tuyên bố miễn trừ trách nhiệm: Tôi tự dạy khóa học này, vì vậy tôi thiên vị]. Bạn sẽ có được phạm vi bảo hiểm tốt về các khía cạnh khác nhau của JVM và tác động của nó đối với O / S và phần cứng cơ bản.

Tái bút: Tôi sẽ cố gắng xem lại điều này sau và dọn dẹp nó.


Sẽ thật sự tuyệt vời nếu những người có kinh nghiệm với Thông cảm cơ học có thể chia sẻ một số thủ thuật để phát hiện khi một ranh giới nhất định đã bị vượt qua.

Tôi đã ping twitter để thử và có được các chuyên gia thực sự trong :-)
Martijn Verburg

Thật tuyệt, Martin Thompson đã theo đuổi, đáng để làm theo lời khuyên của anh ấy đối với tôi.
Martijn Verburg
Khi sử dụng trang web của chúng tôi, bạn xác nhận rằng bạn đã đọc và hiểu Chính sách cookieChính sách bảo mật của chúng tôi.
Licensed under cc by-sa 3.0 with attribution required.