Video học lập trình mỗi ngày

Bài viết này được đưa vào Series: No Code: Ở đây không có code

Tuần đầu tiên của năm 2025. Mục tiêu của 2024 đã được gạch bỏ cho dù nó đẫ hoàn thành hay chưa hoàn thành. Không cần chồng chất những mục tiêu dài hạn từ năm này qua năm khác mà hãy tập trung vào mục tiêu ngắn hạn mỗi năm, và khi qua thời điểm đó, tốt nhất hãy gạch bỏ nó. Và mục tiêu mới được đề ra, tôi thích cách tiếp cận như thế này.

Năm 2024 tôi đặt mục tiêu cho mình 3 mục tiêu, trong đó có mục tiêu phát triển kênh youtube lên 70K Subscribes, nhưng nó đã thất bại khà khà và chỉ đạt 50K Subscribes. OK, năm 2025 tôi lại đặt ra mục tiêu mới cho mình.

Nhưng cũng may mắn rằng, năm qua tôi đã gặp rất nhiều người bạn trong và ngoài nước, cũng như trong ngành và ngoài ngành. Tất cả những người bước qua ta đều đáng phải gặp đúng không?

Và để xem năm nay tôi sẽ vinh dự đón tiếp những ai và trên con đường tôi đi có những vị nào sẽ cùng đồng hành với mình.

Chúc anh chị một năm mới với nhiều mục tiêu đươc thiết lập cho mình và cho gia đình của chính mình...

Chuyện cuối tuần - Vật cực tất phản

Hôm nay tôi muốn đề cập đến một khái niệm mà tôi đọc qua trong cuộc sống là đúng, nhưng trong lập trình cấp độ ngôn ngữ thì tôi thấy nó chưa đúng, nhưng lạ thay với cấp độ doanh nghiệp thì nó lại đúng.

Khái niệm được đề cập như sau: "Diminishing Returns" tôi nghe giang hồ bảo là một khái niệm trong kinh tế học.

Ái chà, trước giờ tôi có biết kinh tế học là gì đâu? Nhưng nếu dịch ra theo kiểu giang hồ nôm na gọi là "Vật cực tất phản" ở trong reddit có mục về cum từ này.

Hiểu theo cách nhìn nhận của tôi nó là "Cái gì đạt tới đỉnh thì ắt sẽ đổi chiều". Trong cuộc sống được mô tả rất nhiều như khi xe lên dốc, và tới đỉnh của dốc thì bắt đầu sẽ xuống dốc, cứ như vậy dốc làm gì có dốc mãi.

Nước tận cùng thành thác đổ, người tận cùng là hồi sinh. Triết lý câu này rất hay trong cuộc sống.

Con người cũng vậy đạt tới đỉnh của tiền bạc thì lại có những phẩm chất xuống dốc. Tôi muốn dừng ở đây, vì tôi không đủ khả năng phân tích thêm.

Vật cực tất phản - Code - Business

Nếu áp dụng "Vật cực tất phản" trong Business có lẽ nó 99% là đúng vì hãy xem một số gã khổng lồ thời của tôi như Nokia, Yahoo!, ToShiba... Họ đã tới đỉnh của con dốc chưa, có lẽ là đến, họ chạm đáy của dốc chưa, có lẽ là chạm, và liệu họ sẽ hồi sinh?

Còn nếu áp dụng trong cấp độ lập trình các ngôn ngữ như JAVA, Go, Nodej, Python thì tôi thấy chưa đúng với câu nói trên. Vì sao? Tôi kể cho các bạn nghe nhanh về câu chuyện "không đúng lắm" tối ưu về Lập trình đồng thời. Tôi lấy JAVA làm ví dụ.

Lập trình đồng thời (Concurrency)

Nếu như các anh chị có học về JAVA thì có lẽ ví dụ này anh chị sẽ dễ hình dung hơn (tốt hơn hết là hiểu về Stream trong JAVA), tôi sẽ đưa ra ví dụ từ lúc sơ khai java 5 đến giờ.

• Lập trình đồng thời (Concurrency) KHÔNG phải là "làm nhiều hơn để có kết quả tốt hơn"

"Diminishing Returns" ngụ ý rằng việc tăng đầu vào (ví dụ: thêm luồng) đến một mức độ nào đó sẽ không mang lại thêm lợi ích, thậm chí gây phản tác dụng.

Nhưng mục tiêu của lập trình đồng thời (với Future, CompletableFuture) không chỉ đơn thuần là "làm nhiều hơn" mà là "làm thông minh hơn", "tận dụng tốt hơn" tài nguyên (CPU) để giảm thời gian chờ đợi, tăng hiệu suất ứng dụng.

Khái niệm "vượt quá giới hạn" trong lập trình đồng thời không chỉ nằm ở số luồng, mà còn ở cách quản lý luồng, xử lý đồng bộ hóa, thiết kế kiến trúc...

• Future, CompletableFuture - Cải tiến, KHÔNG phải "vật cực"

Sự ra đời của Future (Java 5) rồi CompletableFuture (Java 8) là những bước cải tiến trong lập trình đồng thời, không phải là "vật cực" dẫn đến "tất phản".

Trước Future: Lập trình đa luồng (multi-threading) truyền thống khá phức tạp, khó quản lý, dễ xảy ra lỗi (race condition, deadlock).

Future (Java 5): Cung cấp một cách trừu tượng hơn để xử lý kết quả của tác vụ bất đồng bộ, nhưng vẫn còn hạn chế (ví dụ: phải block bằng get(), khó kết hợp các Future).

CompletableFuture (Java 8): Khắc phục những hạn chế của Future, cho phép lập trình bất đồng bộ linh hoạt, dễ dàng kết hợp các tác vụ, xử lý lỗi tốt hơn, nâng cao hiệu suất chứ không phải "làm cho mọi thứ tệ hơn".

Không thể nói: "Dùng CompletableFuture là 'vật cực tất phản' so với Future" vì CompletableFuture rõ ràng là tốt hơn, mạnh mẽ hơn.

• "Quá nhiều luồng" - Vấn đề nằm ở "quản lý", không phải "số lượng"

Đúng là việc tạo ra quá nhiều luồng có thể gây lãng phí tài nguyên, giảm hiệu suất. Nhưng đây là vấn đề về quản lý tài nguyên (resource management), không phải bản chất của lập trình đồng thời hay Future/CompletableFuture.

"Giới hạn" ở đây là khả năng của hệ thống, cách thức sử dụng luồng, chứ không phải là một con số cố định.

Các công cụ như ExecutorService với thread pool giúp quản lý luồng hiệu quả, tránh tạo ra quá nhiều luồng không cần thiết.

Hiểu về Lập trình đồng thời

"Vật cực tất phản" hay "Diminishing Returns" không phản ánh chính xác sự phát triển và cải tiến trong lập trình đồng thời, đặc biệt là với Future và CompletableFuture.

Future và CompletableFuture là những công cụ giúp lập trình viên tận dụng tốt hơn tài nguyên hệ thống, nâng cao hiệu suất ứng dụng, chứ không phải là "làm nhiều hơn để rồi nhận lại ít hơn".

Vấn đề "quá tải" luồng nằm ở cách quản lý, thiết kế chứ không phải ở bản thân các công cụ lập trình đồng thời.

Thay vì "vật cực tất phản", ta nên nói thế này: Lập trình đồng thời cần sự hiểu biết thấu đáo về cách thức hoạt động của các công cụ, kỹ năng thiết kế tốt để tránh các lỗi tiềm ẩn và tối ưu hóa hiệu suất.

Vàd đây chính là những khái niệm tiếp theo tôi sẽ giới thiệu đến anh chị cho những phần tiếp theo đó là Future và CompletableFuture những công cụ mạnh mẽ, giúp đơn giản hóa và nâng cao hiệu quả lập trình bất đồng bộ khi được sử dụng đúng cách.

Xin chào!