🥬
FreshForFresh
  • ✌️Xin chào!
  • Overview
    • 💡Data structures and Algorithms
    • 👀Programming
    • 🧠Database
    • 🦴Back-End
    • ✨Front-End
    • 💐Spring Framework
    • 🛠️Tool
  • Data structures and Algorithms
    • 🎰Data Type
    • 🗑️Garbage collection
    • 🧩Data structures
    • 🎲Algorithms
  • Programming
    • 🧮Compiler
      • 🤖Tại sao phải cần compiler?
      • 📠Java Virtual Machine
  • 📈Thread
  • 🔐Lock & Deadlock
  • 🏇Race condition & Data Race
  • 🧯Synchronized
  • 🗜️Blocking IO và Non Blocking IO Client Server Socket
  • 🌐Languages
    • 🎛️Programming Language
    • 📑Client-Side & Server-Side
    • ⁉️Why java? Why javascript?
  • 🗼Design pattern
    • 🎨Front-End Design Pattern
    • 🏗️Back End Design Pattern
      • 🐴with Java
      • 🦄with Spring Boot
      • 🐖with Modern Backend Development
      • 🐁with Microservice
  • 🍀Clean Code
    • 🌊Chương 1: Code sạch
    • 📐Chương 2: Quy tắc đặt tên rõ nghĩa
    • 🚧Chương 3: Cách viết hàm
    • 👻Chương 4: Comments thế nào cho chuẩn?
    • 🥳Chương 5: Định dạng code.
    • 😈Chương 6: Đối tượng và cấu trúc dữ liệu
    • 🐛Chương 7: Xử lí lỗi
    • ☦️Chương 8: Ranh giới code
    • 🧪Chương 9: Unit test
    • 🥂Chương 10: Lớp đối tượng
    • 🥡Chương 11: Code sạch cấp hệ thống
  • Database
    • 🐔Giới thiệu
    • 📰Các loại cơ sở dữ liệu
    • 🐘Các loại DBMS phổ biến
    • 🕵️‍♀️SQL và cách sử dụng với relational database
      • 👺Lệnh SQL
      • 🛢️JOIN trong SQL
      • 🛕GROUP BY trong SQL
      • 🐼ORDER BY trong SQL
      • 🐣Truy vấn con SUBQUERY trong SQL Server
      • 🏦Transaction Trong SQL
      • 🇲🇰ACID
    • ☢️Thiết kế cơ sở dữ liệu
    • 🕍Consistency and concurrency handling
      • 🔒Database locking
      • 🎮Concurrency Control
      • 🙀Isolation Level
    • 🎨Performance & Scability
      • ☝️Indexing
      • 👯‍♂️Partitioning
      • 💅Các tips tăng hiệu suất SQL
      • 🇲🇬Kiểm tra và Xác thực việc Sao lưu và Phục hồi CSDL
      • 🌠Database sharding
      • 🧘‍♂️REPLICATION
      • 😁Các vấn đề ảnh hưởng đến performance.
  • Back-End
    • 🔫API?
    • 🐕‍🦺Web Services
    • 💾Phân biệt API và web service
    • 🙆‍♂️Tìm hiểu về RestAPI
    • 🧦SOAP
    • ✈️GraphQL API
    • 📊Compared GraphQL & REST
    • 📄Phân biệt HTTP & HTTPS
    • 🚵Client & Server
    • 🇩🇲DOM
  • Front-End
    • 🦑User Interface (UI)
    • 🛰️State Management
  • Spring Framework
    • 🔐Spring Security
      • 🌅Đơn giản hoá Spring Security
      • 🌸Spring Security: Authentication and Authorization In-Depth
      • 🚻OAuth2 Basic
      • 🀄JWT + Spring Security Oauth
      • 📤Logout trong ứng dụng sử dụng bảo mật Oauth
      • 🔂Reset Password
      • 🎗️OAuth2 Remember Me với Refresh Token
      • ⛓️OAuth2 cho một Spring REST API
  • Network
    • 💸Mạng máy tính căn bản
  • Tool
    • 🦏Các câu lệnh Docker cơ bản
    • 🦧Github
      • 🐰Các lệnh Git cơ bản
      • 🐇Một số trường hợp khi sử dụng Git
    • 🏚️WebServer
      • 🪂Tổng quan về kiến trúc hệ thống
      • 🔃Cơ bản về WebServer Nginx
  • Tài nguyên
    • 👨‍🏫Course
    • 📖Docs
Powered by GitBook
On this page
  • Race Condition
  • Hậu quả của race condition
  • Data Races

Race condition & Data Race

Quá trình các threads thực thi lệnh trông như 1 cuộc đua giữa các vận động viên điền kinh olympic vì vậy có thể liên tưởng đến thuật ngữ "Race condition".

PreviousLock & DeadlockNextSynchronized

Last updated 1 year ago

Race Condition

là một tình huống xảy ra khi nhiều threads cùng truy cập và cùng lúc muốn thay đổi dữ liệu (có thể là một biến, một row trong database, một vùng shared data, memory , etc...). Vì thuật toán chuyển đổi việc thực thi giữa các threads có thể xảy ra bất cứ lúc nào, nên không thể biết được thứ tự của các threads truy cập và thay đổi dữ liệu đó sẽ dẫn đến giá trị của data sẽ không như mong muốn. Kết quả sẽ phụ thuộc vào thuật toán thread scheduling của hệ điều hành.

Hậu quả của race condition

Để thấy được hậu quả nghiêm trọng của race condition, ta xét ví dụ sau. Giả sử, ngân hàng B có loại hình cấp thẻ ATM gia đình. Theo đó, hai vợ chồng sở hữu chung một tài khoản, và ngân hàng sẽ phát hành cho mỗi người một thẻ. Cũng giả sử rằng, quy trình rút tiền ở cây ATM của ngân hàng này như sau:

Bước 1: Xác định lượng tiền T đang có trong tài khoản.

Bước 2: Xác định lượng tiền W cần rút.

Bước 3: Nếu W > T thì không thể rút được tiền và quá trình kết thúc. Ngược lại, thực hiện tiếp bước 4.

Bước 4: Đưa lượng tiền W cho người dùng và cập nhật lại lượng tiền trong tài khoản T = T - W.

Xét một cặp vợ chồng đang sở hữu một tài khoản có 10 triệu. Một ngày nọ, người chồng muốn rút 8 triệu ở cây ATM 1, còn người vợ muốn rút 9 triệu ở cây ATM 2. Giả sử, cả hai vợ chồng cùng rút tiền ở một thời điểm. Khi đó, tại bước 1, cả ở cây ATM 1 và cây ATM 2 đều xác định lượng tiền có trong tài khoản là 10 triệu, đều lớn hơn 8 triệu và 9 triệu. Do đó, cả hai vợ chồng đều rút được tiền (tổng cộng 17 triệu), và lượng tiền còn lại có thể là 1 triệu hoặc 2 triệu. Nhưng kết quả hợp lý đáng ra phải là: chỉ có một trong hai người rút được tiền.

Từ ví dụ trên, ta thấy rằng, tài khoản chung của hai vợ chồng chính là một critical resource. Chuỗi thao tác của vợ và chồng ở 2 cây ATM giống như 2 thread. Nếu critical resource không được bảo vệ một cách hợp lý, và 2 thread này cùng truy cập vào, thì có thể khiến cho dữ liệu trong critical resource không còn đúng đắn, hợp lý nữa.

Data Races

Xảy ra khi:

  • Từ 2 thread/process trở lên cùng truy cập vào vùng nhớ chung (shared resource).

  • Ít nhất 1 thread/process thay đổi giá trị của vùng nhớ chung đó.

Có thể gây ra

  • Các giá trị ghi đè lẫn nhau.

  • Đọc ra sai giá trị.

🏇
Race Condition vs Data Races in Java