JavaScript đa luồng


Bùi Việt Tuyết
4 năm trước
Hữu ích 1 Chia sẻ Viết bình luận 0
Đã xem 3225

Cách đây vài tuần, tôi đã đăng 7 lý do mỗi lập trình viên cần học JavaScript . Trong các bình luận, Dean đã cố gắng bác bỏ các lập luận của tôi trước tiên bằng cách tuyên bố rằng các nguồn của tôi về mức độ phổ biến của JavaScript là một vấn đề khó khăn vì JavaScript được sử dụng kết hợp với các ngôn ngữ khác. Tôi bác bỏ quan điểm đó trong các ý kiến. Nhưng sau đó, ông tiếp tục tuyên bố rằng JavaScript JavaScript không phù hợp cho các ứng dụng phía máy khách vì JavaScript là một luồng duy nhất . Lúc này, tôi chỉ thở dài và nhận ra rằng Dean không muốn học JavaScript và rằng PHẢI có một số lý do khiến tôi không thấy lý do tại sao anh ấy lại phê phán JavaScript như vậy.

Nhưng sau đó Brandon đã nhảy vào và đưa ra một sự bảo vệ JavaScript rất rõ ràng ở phía máy chủ, gần như làm cho bài đăng này không cần thiết.

Tuy nhiên, có những điều chưa được nói, và hầu hết mọi người sẽ không bao giờ thấy những bình luận tuyệt vời mà Brandon cung cấp. Và vì vậy chúng tôi xem xét JavaScript đa luồng theo chiều sâu.

JavaScript vs Node.js

Trong bình luận đầu tiên của Brandon, ông chỉ ra một cách chính xác rằng thật không công bằng khi đánh đồng JavaScript ngôn ngữ với môi trường Node.js. Điều này là do Node.js thực sự quay nhiều luồng khi cần để xử lý lưu lượng đến. Trên thực tế, đã có một số thử nghiệm hiệu năng so sánh Node.js với các ứng dụng ASP.NET, tất cả đều thấy rằng Node.js theo kịp hoặc vượt trội so với ASP.NET. Điều này là do cách xử lý lưu lượng. Trong ASP.NET, việc triển khai mặc định là để chặn yêu cầu đến cho đến khi phản hồi cho yêu cầu đó được gửi lại cho máy khách, trong khi cơ chế mặc định trong Node là dành cho yêu cầu KHÔNG chặn. Trong Node, mọi thứ không nên chặn là không chặn. Đây là một chiến thắng HUGE, về cơ bản là tạo ra Node Hồi đa luồng ở những nơi quan trọng mà không phải suy nghĩ về nó.

So sánh tốc độ:

Đây là một ví dụ đơn giản. Bạn đăng dữ liệu từ trình duyệt web lên máy chủ cần vào cơ sở dữ liệu. Trong ASP.NET, cách xử lý mặc định này sẽ là nhận yêu cầu, gửi dữ liệu tới cơ sở dữ liệu, chờ giá trị trả về từ cơ sở dữ liệu và trở về máy chủ. Tất cả như một cuộc gọi chặn.

Trong Node.js, bạn sẽ / có thể thấy hành vi mặc định này. Thông tin được gửi đến máy chủ, máy chủ gửi đến cơ sở dữ liệu không đồng bộ và ngay lập tức trả về máy khách. Tất nhiên, có những vấn đề xử lý lỗi cần được giải quyết ở đây, nhưng điểm chính là bạn KHÔNG phải chờ đợi và có lẽ bạn không nên. Nếu bạn cần gửi lại một thông báo lỗi, điều đó sẽ được xử lý riêng.

Vì vậy, tôi hỏi, cái nào sẽ xuất hiện để nhanh hơn?

Ai cần đa luồng?

ĐƯỢC. Vì vậy, chúng tôi đã giải quyết vấn đề môi trường. Nhưng bây giờ tôi phải hỏi, lần cuối cùng bạn thực sự cần ứng dụng của mình là đa luồng là khi nào? Tôi có thể đếm số lần tôi đã sử dụng các khả năng đa luồng trong một trong các ứng dụng của mình (ứng dụng máy tính để bàn hoặc máy tính để bàn) trên hai tay trong 28 năm lập trình gần đây. Nhu cầu đa luồng khá thấp so với số lượng chương trình được viết. Và ngay cả khi bạn COULD viết một ứng dụng đa luồng, lợi ích so với độ phức tạp trong mã của bạn có xu hướng tương đối nhỏ.

Đa luồng nếu bạn cần - Phía khách hàng

Một tính năng ít được biết đến và thường không được sử dụng đúng mức của JavaScript ở phía máy khách là các nhân viên web, cho phép chúng tôi chạy một tệp JavaScript trong một luồng riêng biệt ở phía máy khách. Nhược điểm của việc sử dụng công nhân là 1) họ không thể truy cập DOM và 2) bạn phải sử dụng tin nhắn để có trang chính và nhân viên nói chuyện với nhau. Nếu bạn thực sự cần đa luồng ở phía máy khách, đây sẽ là cách để làm cho nó hoạt động ngày hôm nay. Nếu bạn cấu trúc mã chính xác, việc tách khỏi DOM không phải là vấn đề và nhắn tin là một cách tuyệt vời để giao tiếp giữa Mô hình xem và Chế độ xem, ngay cả khi không có quy trình xử lý web.

Đa luồng nếu bạn cần - Phía máy chủ

Trong phản hồi ban đầu tôi đã thêm vào vấn đề đa luồng và đề xuất chạy các tiến trình con. Đây là phía máy chủ tương đương với việc sử dụng quy trình worker ở phía máy khách. Bạn sinh ra một số quy trình công nhân, đợi tất cả chúng quay trở lại, thu thập thông tin họ cung cấp và tiếp tục. Như đã chỉ ra, đây không phải là một trò chơi đa luồng thực sự bởi vì trong một ứng dụng đa luồng thực sự, mọi luồng đều có quyền truy cập vào cùng một không gian bộ nhớ. Nhưng bạn có thể tranh luận rằng đây cũng là một điều tốt. Có rất nhiều vấn đề với nhiều luồng truy cập vào cùng một bộ nhớ được chia sẻ. Tôi không chắc chắn tôi sẽ muốn lập trình viên trung bình ABLE làm điều này.

Hôm nay không phải ngày mai

Chỉ vì JavaScript không xử lý đa luồng THỰC SỰ hôm nay, không có nghĩa là điều này sẽ không được thêm vào trong tương lai. Ngôn ngữ vẫn đang phát triển. Tôi có thể thấy một điểm trong năm năm tới khi khả năng này được thêm vào hoặc một khung được tạo sẽ cung cấp khả năng này hoặc cả hai.

Chỉ sử dụng đa luồng khi bạn cần nó

ĐƯỢC. Nhưng nếu bạn THỰC SỰ cần khả năng đa luồng thì sao?

Như đã chỉ ra, thì JavaScript có thể không phải là ngôn ngữ phù hợp cho công việc. Nhưng sau đó, bạn có thể dễ dàng lập luận rằng C #, Java và nhiều ngôn ngữ khác cũng không. Nếu bạn THỰC SỰ cần loại tốc độ đó, có lẽ bạn muốn thả xuống C / C ++ hoặc thậm chí là Ngôn ngữ hội. Nhưng tại sao không trộn và kết hợp? Rất hiếm khi toàn bộ ứng dụng của bạn cần đa luồng. Theo kinh nghiệm của tôi, nó chỉ là một tỷ lệ nhỏ trong tổng số ứng dụng cần khả năng đó. Vậy tại sao không tạo một mô-đun Node thực hiện bit đa luồng và nối nó vào ứng dụng JavaScript rộng hơn của bạn?

Gói nó lên

Rõ ràng, JavaScript là một ngôn ngữ trẻ và Node.js là một môi trường trẻ. Vẫn còn những vấn đề cần được giải quyết. Nhưng đối với những người trẻ tuổi như vậy, họ có một số khả năng khá mạnh mẽ, ra ngoài, sẽ chỉ trở nên tốt hơn trong tương lai.

Tôi rất hào hứng và lạc quan. Vui mừng về tiềm năng và lạc quan về các khả năng trong tương lai để phân luồng trong JavaScript.

Nhưng có lẽ bạn không. Bạn biết những gì, trong khi tôi nghĩ đó có thể là một sai lầm nghề nghiệp, đó là sự nghiệp của bạn. Bạn không cần phải đồng ý với tôi. Và vì cả hai chúng tôi đều không toàn diện, chỉ có thời gian mới cho biết ai trong chúng tôi đưa ra lựa chọn tốt hơn.

Hữu ích 1 Chia sẻ Viết bình luận 0
Đã xem 3225