როგორ ასინქრონიზებთ წვდომას საერთო მდგომარეობაზე?

Question

IT Interview Practice · Accepted Answer

**სინქრონიზაცია** კოორდინირებს ძაფების წვდომას საერთო ცვალებადი მდგომარეობაზე, რათა ოპერაციები არ იყოს საფრთხიანად ერთმანეთზე დაშეთავსებული, **რეის პირობების** თავიდან აცილება. Java გთავაზობთ რამდენიმე მექანიზმს, ჩაშენებული `synchronized` საკვანძოდან აშკარა ჯამურ საშუაოდან და კოდ-თავისუფალ ატომებამდე.

## synchronized — ორმხრივი გამორიცხვა (შინაგანი ჯამურ)

```java
class BankAccount {
    private double balance;

// synchronized method — acquires the object's lock; only ONE thread at a time
    public synchronized void withdraw(double amount) {
        if (balance >= amount) {
            balance -= amount;   // protected — no interleaving
        }
    }
    // synchronized block — finer-grained, lock on a specific object
    public void deposit(double amount) {
        synchronized (this) {
            balance += amount;
        }
    }
}
```

`synchronized` უზრუნველყოფს, რომ მხოლოდ ერთი ძაფი აკრთო დაცული კოდი ერთდროულად (ორმხრივი გამორიცხვა) და უზრუნველყოფს **ხილვადობას** — ერთი ძაფის ცვლილებები ხილვადი ხდება სხვებისთვის (იგი კვეთს მეხსიერების დაბრკოლებას).

## volatile — ხილვადობა ატომიკურობის გარეშე

```java
private volatile boolean running = true;   // guarantees VISIBILITY across threads

public void stop() { running = false; }     // other threads see the change immediately
public void run() { while (running) { ... } } // without volatile, might never see false
```

`volatile` უზრუნველყოფს, რომ ცვლადის კითხვა/ჩაწერა ხილვადია ძაფებში — მაგრამ **არ** აკეთებს რთულ ოპერაციებს (როგორიცაა `count++`) ატომიკური. გამოიყენეთ მარტივი ფლაგებისთვის, არა კითხვის ცვლილების წერისთვის.

## Atomic კლასები — კოდ-ღეფ ატომიკურობა

```java
AtomicInteger counter = new AtomicInteger(0);
counter.incrementAndGet();        // atomic ++ without locking (uses CPU CAS instructions)
counter.compareAndSet(5, 10);     // atomic conditional update
```

Atomic კლასები უზრუნველყოფენ ძაფების უსაფრთხო ოპერაციებს ჯამურის გარეშე — ხშირად უფრო სწრაფი `synchronized` უბრალო სიმრავლეების/აკუმულატორების მიერ.

## აშკარა ჯამურ — მეტი კონტროლი

```java
ReentrantLock lock = new ReentrantLock();
lock.lock();
try {
    // critical section
} finally {
    lock.unlock();   // ALWAYS unlock in finally
}
// ReadWriteLock allows many concurrent readers but exclusive writers
```

`ReentrantLock` გთავაზობთ ფუნქციებს, რომელსაც `synchronized` არ აქვს: `tryLock()` (არა-ბლოკირება), დროებითი ლოდინი, სამართლიანობა და წაკითხვა-წერის გამოყოფა.

## რა რისკები უნდა იყოს მართვა

```text
⚠️ Deadlock — two threads each hold a lock the other needs → both stuck forever
   (avoid by always acquiring locks in a consistent order)
⚠️ Performance — over-synchronizing serializes everything, killing concurrency
   (synchronize the SMALLEST necessary section)
⚠️ Forgetting to unlock (with explicit Locks) → use try/finally
```

## რატომ არის მნიშვნელოვანი

სინქრონიზაცია აუცილებელია სიზუსტისთვის, როდესაც მრავალი ძაფი გამოდის საერთო ცვალებადი მდგომარეობაზე — მის გარეშე, რეის პირობები გამოიწვევენ მონაცემთა ჯვრიანი და შუაღამე ძნელი სამეცნიერო ხარვეზები.

ხელსაყრელი ხელოვანი და მათი ზუსტი გარანტიები: `synchronized` (ორმხრივი გამორიცხვა + ხილვადობა), `volatile` (ხილვადობა მხოლოდ — არა ატომიკურობა, ჯამური უცნობი), atomic კლასები (კოდ-თავისუფალი მარტივი ოპ) და აშკარა ჯამურ (განვითარებული კონტროლი).

თანაბარი მნიშვნელოვანი უნდა იყოს რისკების გააზრება — **deadlock** და over-synchronization ზიანი მოქმედება — და მინიმალური და თანმიმდევრული სინქრონიზაციის დისციპლინა.

ეს არის ძირითადი, მაღალი ხარჯის ცოდნა ერთმიმდევარი სერვერის გვერდის ჯავის და ღრმა ინტერვიუს თემა, რომელიც განასხვავებს დეველოპერებს, რომლებმაც შეუძლიათ სწორი multithreaded კოდი დაწეროს.

synchronized — ორმხრივი გამორიცხვა (შინაგანი ჯამურ)

volatile — ხილვადობა ატომიკურობის გარეშე

Atomic კლასები — კოდ-ღეფ ატომიკურობა

აშკარა ჯამურ — მეტი კონტროლი

რა რისკები უნდა იყოს მართვა

რატომ არის მნიშვნელოვანი

დაკავშირებული კითხვები