🔗 Chaining در CompletableFuture

یکی از قدرت‌های بزرگ CompletableFuture اینه که می‌تونی چندین عملیات Async رو زنجیروار به هم وصل کنی.
این کار باعث می‌شه کدت مرتب‌تر، خواناتر و حرفه‌ای‌تر بشه.


✅ مثال ۱: استفاده از thenApply

import java.util.concurrent.CompletableFuture;

public class ThenApplyExample {
    public static void main(String[] args) {
        CompletableFuture<String> future = CompletableFuture
            .supplyAsync(() -> "Hello")
            .thenApply(s -> s + " World")
            .thenApply(s -> s.toUpperCase());

        System.out.println(future.join());
    }
}

📌 توضیح:

supplyAsync مقدار "Hello" برمی‌گردونه.

thenApply روی نتیجه عملیات قبلی اعمال می‌شه.

خروجی نهایی: HELLO WORLD


✅ مثال ۲: استفاده از thenCompose (برای تو در تو بودن Async)

import java.util.concurrent.CompletableFuture;

public class ThenComposeExample {
    public static void main(String[] args) {
        CompletableFuture<String> future = CompletableFuture
            .supplyAsync(() -> "User123")
            .thenCompose(user -> getUserProfile(user));

        System.out.println(future.join());
    }

    static CompletableFuture<String> getUserProfile(String user) {
        return CompletableFuture.supplyAsync(() -> "Profile of " + user);
    }
}

📌 توضیح:

thenCompose برای زمانی به کار می‌ره که متد قبلی خودش یه CompletableFuture برگردونه.

اینطوری از Future<Future<T>> جلوگیری می‌کنیم و مستقیم یه Future ساده داریم.


✅ مثال ۳: ترکیب چند Future با thenCombine

import java.util.concurrent.CompletableFuture;

public class ThenCombineExample {
    public static void main(String[] args) {
        CompletableFuture<String> future1 = CompletableFuture.supplyAsync(() -> "Hello");
        CompletableFuture<String> future2 = CompletableFuture.supplyAsync(() -> "World");

        CompletableFuture<String> combined = future1.thenCombine(future2, (a, b) -> a + " " + b);

        System.out.println(combined.join());
    }
}

📌 توضیح:

thenCombine دو Future رو ترکیب می‌کنه.

نتیجه: Hello World


🎯 جمع‌بندی

thenApply →
تغییر نتیجه‌ی عملیات قبلی.

thenCompose →
برای عملیات Async تو در تو.

thenCombine →
ترکیب نتایج دو Future مختلف.


با استفاده از این متدها می‌تونی Pipeline‌های Async قدرتمند بسازی که هم سریع‌تر هستن و هم مدیریت‌شون راحت‌تره.

#کاربرـحرفهـای

🆔 @javapro_ir
🆔 @group_javapro

🧠 مدل حافظه در جاوا (Java Memory Model) و نقش volatile

مدل حافظه در جاوا یا JMM مشخص می‌کند که چگونه Threadها به حافظه دسترسی دارند و چه زمانی تغییرات در متغیرها توسط سایر Threadها دیده می‌شود.
این موضوع اهمیت زیادی در برنامه‌های هم‌زمان (Concurrent) دارد، چون بدون آن نتایج غیرقابل پیش‌بینی رخ خواهد داد.



📌 مسئله‌ی اصلی: Visibility و Reordering

برنامه‌های چندنخی در جاوا روی پردازنده‌ها اجرا می‌شوند و پردازنده‌ها برای افزایش سرعت، دستورها را ممکن است بازچینی (Reorder) کنند. همچنین هر Thread معمولاً داده‌ها را در Cache محلی خودش نگه می‌دارد.

به همین دلیل دو مشکل اصلی ایجاد می‌شود:

Visibility (قابلیت مشاهده):
یک Thread مقدار جدید متغیر را تغییر می‌دهد اما سایر Threadها همچنان مقدار قدیمی را می‌بینند.

Reordering (بازچینی):
دستورها توسط CPU یا کامپایلر جابه‌جا می‌شوند و در نتیجه Thread دیگر ترتیب مورد انتظار را نمی‌بیند.



✅ نقش volatile

کلمه‌ی کلیدی volatile به جاوا می‌گوید که:

1. همیشه مقدار متغیر از حافظه اصلی (Main Memory) خوانده شود.


2. هر تغییر در متغیر بلافاصله برای سایر Threadها قابل مشاهده باشد.


3. بازچینی دستورها (Reordering) برای دسترسی به این متغیر ممنوع شود.




🔎 مثال بدون volatile (رفتار اشتباه)

public class WithoutVolatile {
    private static boolean running = true;

    public static void main(String[] args) throws InterruptedException {
        Thread worker = new Thread(() -> {
            while (running) {
                // مشغول کار
            }
            System.out.println("Worker stopped!");
        });

        worker.start();

        Thread.sleep(1000);
        running = false; // تلاش برای توقف
        System.out.println("Flag set to false");
    }
}

📌 مشکل:

در اینجا ممکن است Thread worker هیچ‌وقت متوقف نشود، چون مقدار running در Cache Thread گیر کرده و تغییرش در Thread اصلی دیده نمی‌شود.



🔎 مثال با volatile (رفتار درست)

public class WithVolatile {
    private static volatile boolean running = true;

    public static void main(String[] args) throws InterruptedException {
        Thread worker = new Thread(() -> {
            while (running) {
                // مشغول کار
            }
            System.out.println("Worker stopped!");
        });

        worker.start();

        Thread.sleep(1000);
        running = false; // توقف درست انجام می‌شود
        System.out.println("Flag set to false");
    }
}

📌 توضیح:

با volatile تغییر مقدار متغیر running بلافاصله به حافظه اصلی فرستاده می‌شود.

بنابراین Thread worker به‌محض تغییر متغیر، مقدار جدید را می‌بیند و متوقف می‌شود.



🎯 جمع‌بندی

در واقع Java Memory Model مشخص می‌کند که Threadها چگونه حافظه را می‌بینند.

مشکلات اصلی در Multithreading Visibility و Reordering هستند.

کلیدواژه volatile تضمین می‌کند که تغییرات یک متغیر بلافاصله توسط همه‌ی Threadها قابل مشاهده باشد و دستورات مربوط به آن بازچینی نشوند.

#کاربرـپیشرفته

🆔 @javapro_ir
🆔 @group_javapro

⚖️ تفاوت Checked و Unchecked Exceptions در جاوا

برنامه‌نویسی در جاوا بدون Exception Handling معنایی ندارد. جاوا برای مدیریت خطاها دو نوع Exception تعریف کرده است: Checked و Unchecked. این تمایز به ظاهر ساده است، اما تاثیر بزرگی بر طراحی APIها و ساختار کد دارد.



📌 Checked Exceptions

درواقع Checked Exception ها خطاهایی هستند که کامپایلر شما را مجبور می‌کند مدیریت‌شان کنید.

یا باید آن‌ها را با try-catch بگیرید، یا باید با throws در امضای متد اعلام کنید.

این Exceptions معمولاً برای خطاهای قابل پیش‌بینی و بازیابی‌پذیر استفاده می‌شوند.


🔎 مثال:

import java.io.*;

public class CheckedExample {
    public static void main(String[] args) {
        try {
            FileReader reader = new FileReader("file.txt"); // FileNotFoundException
            reader.read(); // IOException
        } catch (IOException e) {
            System.out.println("خطا: " + e.getMessage());
        }
    }
}

📌 در این مثال، جاوا ما را مجبور می‌کند که IOException را مدیریت کنیم.



📌 Unchecked Exceptions

در واقع Unchecked Exception ها زیرکلاس‌های RuntimeException هستند.

کامپایلر ما را مجبور به مدیریت آن‌ها نمی‌کند.

این Exceptions معمولاً برای خطاهای برنامه‌نویسی مثل NullPointerException، ArrayIndexOutOfBoundsException یا IllegalArgumentException استفاده می‌شوند.


🔎 مثال:

public class UncheckedExample {
    public static void main(String[] args) {
        String text = null;
        System.out.println(text.length()); // NullPointerException
    }
}

📌 در اینجا هیچ اجباری از طرف کامپایلر برای مدیریت خطا وجود ندارد.




🎯 چرا این تمایز وجود دارد؟

در واقع Checked Exceptions به ما یادآوری می‌کنند که خطاهایی وجود دارند که باید آن‌ها را جدی بگیریم (مثل IO یا دسترسی به شبکه).

و Unchecked Exceptions برای خطاهایی هستند که ناشی از اشتباه برنامه‌نویس‌اند و معمولاً نباید recover شوند (مثل استفاده از null).




⚡ تاثیر روی طراحی APIها

اگر API شما با منابع خارجی (فایل، شبکه، دیتابیس) سروکار دارد → بهتر است Checked Exception برگرداند.

اگر API شما ورودی نامعتبر یا خطای منطقی دارد → معمولاً Unchecked Exception بهتر است.


🔎 مثال طراحی API:

// Checked Exception: نشان می‌دهد که خطا قابل انتظار است
public void readFile(String path) throws IOException {
    // ...
}

// Unchecked Exception: نشان می‌دهد که خطا ناشی از ورودی اشتباه است
public void setAge(int age) {
    if (age < 0) {
        throw new IllegalArgumentException("سن نمی‌تواند منفی باشد");
    }
}

✅ جمع‌بندی

Checked Exceptions →
قابل پیش‌بینی، باید مدیریت شوند.

Unchecked Exceptions →
خطاهای برنامه‌نویسی، اجباری برای مدیریت ندارند.

این تمایز باعث می‌شود APIها شفاف‌تر باشند و توسعه‌دهنده بداند کجا باید به خطا اهمیت دهد.

#کاربرـحرفهـای

🆔 @javapro_ir
🆔 @group_javapro

⚖️ چرا باید equals و hashCode با هم Override شوند؟

برنامه‌نویسی شیءگرا در جاوا به شدت بر پایه‌ی مقایسه‌ی اشیاء است.
دو متد مهم که در این زمینه نقش حیاتی دارند، equals و hashCode هستند.



📌 متد equals

برای مقایسه‌ی محتوای دو شیء استفاده می‌شود.

به صورت پیش‌فرض از کلاس Object به ارث می‌رسد و فقط مقایسه‌ی آدرس حافظه انجام می‌دهد.

معمولاً باید آن را Override کنیم تا بتوانیم دو شیء با محتوای یکسان را برابر در نظر بگیریم.




📌 متد hashCode

این متد یک عدد صحیح (int) برمی‌گرداند که نشان‌دهنده‌ی یک Hash برای شیء است.

در ساختارهایی مثل HashMap, HashSet و Hashtable برای سریع پیدا کردن اشیاء استفاده می‌شود.

قرارداد جاوا می‌گوید:

اگر a.equals(b) درست باشد، باید a.hashCode() == b.hashCode() هم درست باشد.





🔎 مشکل وقتی فقط equals را Override کنیم

import java.util.HashSet;

class Person {
    String name;

    Person(String name) {
        this.name = name;
    }

    @Override
    public boolean equals(Object o) {
        if (this == o) return true;
        if (!(o instanceof Person)) return false;
        Person person = (Person) o;
        return name.equals(person.name);
    }
}

public class Test {
    public static void main(String[] args) {
        HashSet<Person> set = new HashSet<>();
        set.add(new Person("Ali"));

        System.out.println(set.contains(new Person("Ali"))); // false
    }
}

📌 توضیح:

ما equals را Override کردیم اما hashCode را نه.

در واقع HashSet ابتدا hashCode را چک می‌کند تا موقعیت را پیدا کند. چون hashCode پیش‌فرض برای دو شیء متفاوت است، حتی اگر equals درست باشد، شیء پیدا نمی‌شود.




🔎 مثال درست با Override هر دو متد

import java.util.HashSet;
import java.util.Objects;

class Person {
    String name;

    Person(String name) {
        this.name = name;
    }

    @Override
    public boolean equals(Object o) {
        if (this == o) return true;
        if (!(o instanceof Person)) return false;
        Person person = (Person) o;
        return name.equals(person.name);
    }

    @Override
    public int hashCode() {
        return Objects.hash(name);
    }
}

public class Test {
    publiSystem.out.println(String[] args) {
        HashSet<Person> set = new HashSet<>();
        set.add(new Person("Ali"));

        System.out.println(set.contains(new Person("Ali"))); // true
    }
}

📌 حالا چون هم equals و هم hashCode درست Override شده‌اند، مجموعه به درستی کار می‌کند.




🎯 جمع‌بندی

equals:
محتوای اشیاء را مقایسه می‌کند.

hashCode:
برای جست‌وجوی سریع در Collectionهای مبتنی بر Hash استفاده می‌شود.

اگر equals را Override کردید، حتماً باید hashCode را هم Override کنید، وگرنه ساختارهایی مثل HashSet و HashMap رفتار غیرمنتظره خواهند داشت.

#کاربرـپیشرفته

🆔 @javapro_ir
🆔 @group_javapro