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

Phân biệt Nested Classes và Inner Classes

Khái niệm Type Aliases

Type Aliases cho phép định nghĩa một tên gọi thay thế (alias) cho các kiểu dữ liệu đã tồn tại. Nó không tạo ra một kiểu dữ liệu mới hoàn toàn mà chỉ cung cấp một định danh ngắn gọn và dễ hiểu hơn cho kiểu dữ liệu gốc.

Data Classes trong Kotlin được thiết kế để lưu trữ dữ liệu với các phương thức tự động sinh ra như equals(), hashCode(), toString(), và copy().

Extension Functions cho phép mở rộng chức năng của một lớp mà không cần kế thừa, trong khi Member Functions là các phương thức được định nghĩa bên trong lớp đó.

Type Inference là khả năng trình biên dịch Kotlin tự động xác định kiểu dữ liệu của biến dựa trên giá trị khởi tạo.

Sealed Classes cho phép định nghĩa một hệ thống phân cấp lớp đóng, nơi tất cả các lớp con được biết trước tại thời điểm biên dịch.

Đây là hai kiểu dữ liệu đặc biệt trong hệ thống phân cấp kiểu của Kotlin.

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.

Trong phát triển dự án với Kotlin, việc tối ưu hóa và quản lý tốt Null Safety validation là vô cùng quan trọng để đảm bảo tính ổn định và hiệu năng của hệ thống. Dưới đây là các khía cạnh kỹ thuật cốt lõi:

Trong phát triển dự án với Kotlin, việc tối ưu hóa và quản lý tốt Functional Programming API là vô cùng quan trọng để đảm bảo tính ổn định và hiệu năng của hệ thống. Dưới đây là các khía cạnh kỹ thuật cốt lõi:

Phân tích cơ chế

• Dispatchers.Default: Được tối ưu hóa cho các tác vụ tiêu tốn CPU (CPU-intensive), ví dụ như tính toán thuật toán, xử lý ảnh, hoặc phân tích dữ liệu lớn. Nó sử dụng một Thread Pool có kích thước bằng số nhân CPU của máy.
• Dispatchers.IO: Được thiết kế cho các tác vụ chặn (blocking) như đọc/ghi file, truy vấn Database, hoặc gọi API qua mạng. Nó sử dụng một Thread Pool linh hoạt, có thể mở rộng lên đến 64 thread (hoặc nhiều hơn tùy cấu hình) để đảm bảo các tác vụ I/O không làm nghẽn luồng xử lý chính.

Tại sao chọn sai gây suy giảm hiệu năng?

Nếu sử dụng Dispatchers.Default cho các tác vụ I/O, số lượng thread bị giới hạn sẽ khiến các tác vụ I/O phải chờ đợi nhau (queueing), dẫn đến hiện tượng nghẽn cổ chai. Ngược lại, nếu dùng Dispatchers.IO cho các tác vụ tính toán nặng, việc chuyển đổi ngữ cảnh (context switching) liên tục giữa quá nhiều thread sẽ gây lãng phí tài nguyên CPU và làm chậm ứng dụng.