Thư Viện Câu Hỏi Phỏng Vấn

Bản chất cơ chế

Trong Go lang, mọi thứ đều được truyền theo cơ chế Pass by Value (Truyền tham trị), bao gồm cả con trỏ (Pointer). Khi bạn truyền một biến vào hàm, Go sẽ tạo một bản sao (copy) của giá trị đó và đưa vào hàm. Nếu truyền một con trỏ, bản sao được tạo ra chính là bản sao của địa chỉ ô nhớ (memory address) chứ không phải bản sao của toàn bộ dữ liệu cấu trúc.

Bản chất cơ chế

Race Condition xảy ra khi hai hoặc nhiều Goroutines truy cập cùng một vùng nhớ đồng thời và ít nhất một quyền truy cập là thao tác ghi (write), dẫn đến dữ liệu bị sai lệch hoặc ứng dụng bị crash.

Khi lập trình viên thực hiện lệnh git reset --hard không đúng cách, các thay đổi chưa commit hoặc các commit mới tạo có thể biến mất khỏi lịch sử nhánh hiện tại. Để khôi phục lại, chúng ta sử dụng cơ chế Git Reflog.

Trong quản lý mã nguồn, việc đồng bộ hóa dữ liệu từ remote repository về local repository là cực kỳ quan trọng. Dưới đây là phân tích chi tiết sự khác biệt giữa hai lệnh này.

Merge Conflict xảy ra khi Git không thể tự động hợp nhất các dòng code do có sự thay đổi chồng chéo trên cùng một vị trí của tệp tin giữa hai nhánh.

Tệp .gitignore đóng vai trò định nghĩa các tệp tin và thư mục mà Git sẽ bỏ qua, không theo dõi (track) trong kho lưu trữ mã nguồn.

Trong quá trình phát triển, việc quên thêm một tệp nhỏ hoặc viết sai chính tả trong thông điệp commit gần nhất là rất phổ biến. Thay vì tạo một commit mới với nội dung như 'fix typo', chúng ta sử dụng tính năng Git Amend.

Bản chất cơ chế hoạt động

• val (value) đại diện cho một tham chiếu chỉ đọc (read-only reference). Khi một biến được khai báo là val, giá trị của nó không thể được gán lại sau khi đã khởi tạo lần đầu (immutable reference). Tuy nhiên, cần lưu ý rằng đối tượng bên trong vẫn có thể thay đổi trạng thái nếu nó là mutable.
• var (variable) đại diện cho một biến có thể thay đổi giá trị (mutable variable), cho phép gán lại nhiều lần trong vòng đời.

Tác động trong môi trường Enterprise

• Lạm dụng var làm tăng độ phức tạp của mã nguồn, đặc biệt trong các ứng dụng đa luồng (multi-threaded applications) hoặc kiến trúc hướng sự kiện (event-driven architecture). Khi trạng thái có thể bị thay đổi tự do bởi bất kỳ hàm nào, việc theo dõi luồng dữ liệu (data flow) trở nên khó khăn, dễ dẫn đến các lỗi khó phát hiện như race conditions hoặc side effects không mong muốn.
• Sử dụng val giúp thúc đẩy lập trình hướng bất biến (immutability), giúp mã nguồn dễ đoán hơn, dễ viết Unit Test và an toàn hơn khi chạy đồng thời.

Ví dụ minh họa

class UserService {
    // Khuyến nghị: Sử dụng val cho các thuộc tính không đổi
    private val maxRetryCount = 3

    fun processUser(userId: String) {
        // Tránh dùng var nếu không thực sự cần thiết gán lại giá trị
        var attempts = 0 
        while (attempts < maxRetryCount) {
            try {
                // Xử lý logic kết nối
                break
            } catch (e: Exception) {
                attempts++
            }
        }
    }
}

Lưu ý kinh nghiệm thực chiến

Ở cấp độ Junior, lập trình viên thường có thói quen dùng var cho mọi biến số vì tính tiện lợi. Trong các dự án Enterprise tại Unicode Academy, chúng tôi luôn yêu cầu ưu tiên tuyệt đối val, và chỉ sử dụng var khi thực sự bắt buộc phải thay đổi trạng thái trong một phạm vi hẹp (local scope).

Bản chất cơ chế hoạt động

• Kotlin được thiết kế để giải quyết triệt để vấn đề Null Safety thông qua hệ thống kiểu phân biệt rõ ràng giữaNullable và Non-null types.
• Tuy nhiên, khi gọi mã từ Java, Kotlin không thể biết chắc chắn liệu một phương thức Java có trả về giá trị null hay không do Java không có hệ thống Null Safety tương tự. Kotlin giải quyết việc này bằng cách sử dụng Platform Types (ký hiệu bằng dấu chấm hỏi kép T!). Platform Types cho phép lập trình viên tùy ý coi kiểu dữ liệu đó là nullable hoặc non-null.

Các bước xử lý an toàn

1. Sử dụng Safe Calls (?.): Tránh gọi trực tiếp phương thức trên đối tượng Java nếu chưa chắc chắn nó khác null.
2. Sử dụng Elvis Operator (?:): Cung cấp giá trị mặc định khi gặp giá trị null.
3. Sử dụng Not-null Assertion (!!): Chỉ dùng khi tuyệt đối chắc chắn Java trả về giá trị non-null, nếu không sẽ ném ra NullPointerException.
4. Khai báo Annotation phía Java: Sử dụng các annotation như @NotNull và @Nullable trong mã nguồn Java để Kotlin nhận diện chính xác kiểu dữ liệu.

Ví dụ minh họa

// Giả sử gọi một phương thức từ thư viện Java cũ
val javaUser: JavaUser? = LegacyJavaLibrary.getUser()

// Xử lý an toàn bằng Safe Calls và Elvis Operator
val userName: String = javaUser?.name ?: "Unknown"

// Xử lý khi Java không có annotation
val email = javaUser?.email.orEmpty()

Lưu ý kinh nghiệm thực chiến

Khi tích hợp các thư viện Java trong dự án Enterprise lớn, không bao giờ lạm dụng toán tử !!. Nếu thư viện Java không có sẵn annotation quản lý null, hãy luôn giả định rằng giá trị trả về có thể là null và áp dụng chiến lược phòng thủ mã nguồn (defensive programming).

Bản chất cơ chế hoạt động

• lateinit var:
  • Dùng cho kiểu dữ liệu biến đổi (var) không phải kiểu nguyên thủy (primitive types như Int, Boolean).
  • Cho phép hoãn thời điểm khởi tạo giá trị của biến sau khi đối tượng đã được khởi tạo (thường dùng trong Dependency Injection hoặc Android Activity/Fragment lifecycle).
  • Nếu truy cập biến lateinit trước khi nó được gán giá trị, hệ thống sẽ ném ra ngoại lệ UninitializedPropertyAccessException.
• val lazy:
  • Dùng cho thuộc tính chỉ đọc (val).
  • Giá trị chỉ được tính toán và khởi tạo tại lần truy cập đầu tiên (lazy initialization).
  • Mặc định cơ chế thread-safety là LazyThreadSafetyMode.SYNCHRONIZED, đảm bảo chỉ có một luồng thực thi việc khởi tạo.

Bảng so sánh nhanh

• lateinit: Dùng cho var, khởi tạo thủ công sau, không hỗ trợ kiểu nguyên thủy.
• lazy: Dùng cho val, tự động khởi tạo khi gọi lần đầu, hỗ trợ mọi kiểu dữ liệu.

Ví dụ minh họa

class DatabaseManager {
    // lateinit dùng khi phụ thuộc vào Dependency Injection
    @Inject
    lateinit var connectionPool: ConnectionPool

    // lazy dùng khi tài nguyên nặng, chỉ khởi tạo khi thực sự cần thiết
    val heavyConfiguration: ConfigData by lazy {
        ConfigData.loadFromDisk()
    }
}

Lưu ý kinh nghiệm thực chiến

Lập trình viên Junior thường hay nhầm lẫn hai khái niệm này. Hãy nhớ nguyên tắc vàng: Dùng lateinit khi bạn biết chắc chắn giá trị sẽ được gán trước khi sử dụng (nhưng chưa thể gán lúc khai báo). Dùng lazy khi bạn muốn tối ưu hóa hiệu năng, hoãn việc tải tài nguyên nặng cho đến thời điểm gọi lần đầu tiên.

Bản chất cơ chế hoạt động

Scope Functions là các hàm có nhiệm vụ duy nhất là thực thi một khối mã trong ngữ cảnh của một đối tượng. Sự khác biệt giữa chúng nằm ở hai yếu tố:

Bản chất cơ chế hoạt động

• Coroutine trong Kotlin không gắn liền với một luồng cụ thể nào. Một Coroutine có thể tạm dừng (suspend) việc thực thi trên một luồng và tiếp tục chạy trên một luồng khác.
• Dispatcher chịu trách nhiệm quyết định coroutine nào sẽ được thực thi trên luồng nào bằng cách quản lý mộtpool các luồng (thread pool).
• Các Dispatcher phổ biến:
  • Dispatchers.Main: Chạy trên luồng chính (thường dùng cho UI operations).
  • Dispatchers.Default: Được tối ưu cho các tác vụ nặng về CPU (CPU-bound) như xử lý thuật toán, parsing dữ liệu lớn. Số lượng luồng bằng số lượng nhân CPU.
  • Dispatchers.IO: Được tối ưu cho các tác vụ đọc ghi mạng, truy vấn cơ sở dữ liệu hoặc đọc ghi file (I/O-bound). Pool luồng của Dispatchers.IO có thể mở rộng linh hoạt (lên đến 64 luồng hoặc số nhân CPU tùy theo giá trị lớn hơn).

Vai trò trong Enterprise

Trong các ứng dụng backend hoặc mobile quy mô lớn, việc chặn luồng chính (blocking main thread) sẽ làm sập ứng dụng hoặc gây nghẽn cổ chai hệ thống. Dispatchers.IO giúp chia sẻ tài nguyên hiệu quả, cho phép xử lý hàng ngàn request đồng thời mà không làm cạn kiệt tài nguyên hệ thống nhờ cơ chế chia sẻ chung một shared thread pool.

Bản chất cơ chế Tail Recursion

Tail Recursion là một trường hợp đặc biệt của đệ quy, trong đó lời gọi đệ quy là thao tác cuối cùng được thực hiện trong hàm. Không có tính toán nào được thực hiện sau khi lời gọi đệ quy trả về.

Bản chất vấn đề

Việc tính toán số Fibonacci (đặc biệt khi dùng thuật toán kém tối ưu hoặc với N rất lớn) tiêu tốn rất nhiều CPU (CPU-intensive). Nếu một client gửi hàng loạt request liên tục, hệ thống microservice sẽ nhanh chóng rơi vào trạng thái nghẽn cổ chai, dẫn đến sập toàn bộ dịch vụ.

Bản chất cơ chế Lazy Evaluation

Khi cần sinh ra một dãy số Fibonacci dài (hoặc vô hạn), việc lưu trữ toàn bộ kết quả vào một mảng (Array/List) trong bộ nhớ RAM sẽ gây lãng phí tài nguyên. Kỹ thuật Lazy Evaluation thông qua Generator cho phép tính toán và trả về từng giá trị một cách tuần tự theo nhu cầu (on-demand).