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

Khi gọi sort() không tham số, JavaScript sẽ chuyển đổi các phần tử thành chuỗi (string) và so sánh theo thứ tự mã Unicode (UTF-16). Đối với mảng đối tượng, kết quả sẽ là '[object Object]', dẫn đến việc không thể sắp xếp đúng ý đồ. Để sắp xếp mảng đối tượng, bạn phải cung cấp một hàm so sánh (compare function) nhận vào hai tham số a và b. Ví dụ: data.sort((a, b) => a.price - b.price);. Hàm này trả về giá trị âm nếu a < b, dương nếu a > b, và 0 nếu bằng nhau. Đây là tiêu chuẩn để đảm bảo tính chính xác trong logic nghiệp vụ.

Insertion Sort có độ phức tạp O(n^2) trong trường hợp xấu nhất, nhưng nó cực kỳ hiệu quả đối với các tập dữ liệu nhỏ (thường dưới 10-20 phần tử) hoặc dữ liệu đã gần như được sắp xếp sẵn. Do chi phí khởi tạo thấp và tính ổn định (stable), các thuật toán hiện đại như Timsort (sử dụng trong V8 engine của Chrome) kết hợp Merge Sort với Insertion Sort để tối ưu hóa hiệu năng trên các phân đoạn nhỏ, giúp giảm thiểu chi phí đệ quy và tối ưu hóa bộ nhớ đệm (cache locality).

Việc sắp xếp tại Database tận dụng tối đa các chỉ mục (Index) đã được tối ưu hóa sẵn. Khi dữ liệu lớn, việc truyền tải toàn bộ tập dữ liệu về ứng dụng (Application-level) gây lãng phí băng thông mạng và tiêu tốn bộ nhớ RAM của Server. Ngoài ra, Database có khả năng thực hiện sắp xếp ngoài (External Sorting) nếu dữ liệu vượt quá RAM. Việc dùng ORDER BY kết hợp với LIMIT và OFFSET còn giúp triển khai tính năng phân trang (pagination) hiệu quả, giảm tải cho hệ thống.

Một thuật toán sắp xếp ổn định (Stable Sort) là thuật toán giữ nguyên thứ tự tương đối của các phần tử có giá trị bằng nhau. Nếu thuật toán không ổn định, khi bạn sắp xếp theo tên sản phẩm sau khi đã sắp xếp theo giá, các sản phẩm có cùng giá sẽ bị xáo trộn thứ tự tên ban đầu. Điều này gây trải nghiệm người dùng kém và khó kiểm soát dữ liệu. Trong thực tế, các thư viện chuẩn như Array.prototype.sort() trong các phiên bản ECMAScript mới đã được quy định là ổn định để đảm bảo tính nhất quán này.

QuickSort dựa trên cơ chế đệ quy. Nếu chọn phần tử chốt (pivot) không tốt (ví dụ mảng đã sắp xếp sẵn), độ sâu của đệ quy có thể đạt đến O(n), dẫn đến tràn ngăn xếp (Stack Overflow). Để khắc phục, Junior cần: 1. Sử dụng chiến lược chọn pivot ngẫu nhiên hoặc chọn trung vị (median-of-three). 2. Chuyển đổi đệ quy thành vòng lặp với ngăn xếp thủ công. 3. Sử dụng các thuật toán thay thế như Heap Sort (độ phức tạp O(n log n) ổn định và không cần đệ quy sâu) hoặc tận dụng các thư viện đã được tối ưu hóa của ngôn ngữ lập trình.

Việc sử dụng tx.origin để kiểm tra quyền truy cập là một lỗ hổng bảo mật kinh điển vì nó đại diện cho địa chỉ tài khoản đã khởi tạo giao dịch ban đầu, không phải địa chỉ của Smart Contract đang gọi hàm. Kẻ tấn công có thể tạo một hợp đồng trung gian (Attacker Contract) để lừa người dùng (hoặc chủ sở hữu hợp đồng) thực hiện một giao dịch gọi vào hợp đồng của kẻ tấn công. Khi đó, tx.origin vẫn là địa chỉ của người dùng, khiến các hàm kiểm tra quyền bị vượt qua. Thay vào đó, hãy luôn sử dụng msg.sender để xác thực vì nó đại diện cho thực thể trực tiếp gọi vào hàm hiện tại. Ví dụ: thay vì require(tx.origin == owner), hãy dùng require(msg.sender == owner).

Shadowing xảy ra khi một biến trong phạm vi con (ví dụ: biến cục bộ hoặc biến trong hợp đồng kế thừa) có cùng tên với một biến trong phạm vi cha hoặc phạm vi toàn cục. Điều này khiến trình biên dịch ghi đè hoặc gây nhầm lẫn khi truy xuất giá trị, dẫn đến việc hợp đồng đọc sai dữ liệu lưu trữ. Để tránh điều này, cần tuân thủ quy tắc đặt tên rõ ràng, sử dụng tiền tố (như hoặc m) cho các biến trạng thái hoặc biến tham số. Trình biên dịch Solidity hiện đại sẽ đưa ra cảnh báo (warning) khi phát hiện shadowing; nhà phát triển tuyệt đối không được bỏ qua các cảnh báo này để đảm bảo tính toàn vẹn của dữ liệu.

Blockchain là môi trường tất định (deterministic), nghĩa là mọi node đều phải tính toán ra cùng một kết quả. Các biến như block.timestamp, block.difficulty hay blockhash đều có thể bị thao túng bởi các thợ đào (miners) hoặc validator để thay đổi kết quả ngẫu nhiên theo ý muốn. Để tạo số ngẫu nhiên an toàn trong Enterprise, cần sử dụng các giải pháp Oracle phi tập trung như Chainlink VRF (Verifiable Random Function). Chainlink VRF cung cấp bằng chứng mã hóa chứng minh tính ngẫu nhiên của con số được tạo ra, đảm bảo tính công bằng và không thể bị can thiệp bởi bất kỳ bên nào.

Lưu trữ dữ liệu vào Storage (biến trạng thái) là thao tác tốn kém nhất trong Solidity vì dữ liệu được ghi vĩnh viễn vào trạng thái của blockchain và mọi node đều phải lưu trữ. Ngược lại, Event là cơ chế ghi dữ liệu vào log của giao dịch. Dữ liệu trong Event không thể được truy cập bởi các Smart Contract khác, nhưng nó rẻ hơn đáng kể và cho phép các ứng dụng Frontend (thông qua Web3.js hoặc Ethers.js) truy vấn dữ liệu lịch sử một cách hiệu quả. Kinh nghiệm thực chiến là chỉ lưu trữ vào Storage những dữ liệu cần thiết cho logic của hợp đồng, còn lại hãy sử dụng Event để lưu trữ dữ liệu phục vụ mục đích hiển thị hoặc phân tích.

Modifier giúp tách biệt logic kiểm tra (validation logic) ra khỏi logic nghiệp vụ chính của hàm, giúp mã nguồn trở nên sạch sẽ, dễ đọc và dễ bảo trì (DRY - Don't Repeat Yourself). Về mặt bảo mật, nó đảm bảo các điều kiện tiên quyết (như kiểm tra quyền, trạng thái hợp đồng) được thực thi nhất quán trước khi code chính của hàm chạy. Nếu không sử dụng modifier, việc lặp lại các câu lệnh require() ở đầu mỗi hàm dễ dẫn đến sai sót hoặc quên kiểm tra trong các bản cập nhật sau này. Ví dụ: modifier onlyOwner { require(msg.sender == owner); _; } giúp đảm bảo tính an toàn cho các hàm quản trị quan trọng.

Bản chất vấn đề

Khi duyệt cây bằng đệ quy, mỗi lần gọi hàm, hệ thống sẽ tạo một Stack Frame mới để lưu trữ biến cục bộ và địa chỉ trả về. Nếu cây có độ sâu quá lớn (ví dụ cây bị lệch - Skewed Tree), số lượng Stack Frame sẽ vượt quá dung lượng bộ nhớ Stack được cấp phát, gây ra lỗi Stack Overflow.

Phân tích hiệu năng

1. Hash Table: Mặc dù tìm kiếm theo khóa chính mất O(1), nhưng không hỗ trợ tìm kiếm tiền tố (Prefix Search) hiệu quả. Để tìm các từ bắt đầu bằng 'uni', bạn phải duyệt qua toàn bộ bảng băm, gây lãng phí tài nguyên.
2. Mảng: Tìm kiếm nhị phân trên mảng đã sắp xếp mất O(k * log n) với k là độ dài từ. Tuy nhiên, việc chèn thêm từ mới rất tốn kém do phải dịch chuyển phần tử.
3. Trie (Prefix Tree):
   • Độ phức tạp tìm kiếm là O(m) với m là độ dài của tiền tố, độc lập với số lượng từ có trong tập dữ liệu.
   • Chia sẻ tiền tố chung giữa các từ, giúp tiết kiệm bộ nhớ khi lưu trữ tập từ vựng lớn.

Ứng dụng thực chiến

Trong các hệ thống Enterprise, Trie thường được tối ưu bằng cách sử dụng Compressed Trie (Radix Tree) để giảm số lượng nút trung gian, từ đó giảm thiểu số lần truy cập bộ nhớ (Cache Misses) và tăng tốc độ phản hồi cho người dùng.

Bản chất của BST

Cây tìm kiếm nhị phân (BST) duy trì tính chất: mọi nút ở nhánh trái đều nhỏ hơn nút gốc, và mọi nút ở nhánh phải đều lớn hơn nút gốc. Tính chất này được bảo toàn đệ quy trên toàn bộ các cây con.

Lỗi logic thường gặp

Nhiều lập trình viên Junior thường chỉ kiểm tra điều kiện: node.left.val < node.val < node.right.val. Cách này sai vì nó không kiểm tra được các nút ở nhánh con xa hơn. Ví dụ: một nút bên phải của gốc có thể nhỏ hơn gốc, vi phạm tính chất BST.

Các trường hợp xóa nút

1. Nút lá: Chỉ cần xóa trực tiếp.
2. Nút có một con: Thay thế nút đó bằng nút con duy nhất.
3. Nút có hai con: Đây là trường hợp phức tạp nhất.

Tại sao chọn In-order Successor?

In-order Successor là nút nhỏ nhất trong cây con bên phải. Việc thay thế nút bị xóa bằng giá trị này đảm bảo: