https://virgool.io/feed/@rasool Software engineer fa 2026-06-19 19:50:59 https://files.virgool.io/upload/users/15363/avatar/SvHoY6.png?height=120&width=120 https://virgool.io/@rasool https://virgool.io/javacup/multithreading-in-java-introduction-gr16uciaudds یکی از مفاهیم خیلی خیلی مهم در برنامه نویسی مبحثی قشنگ و باحالی هست به نام چند نخی ! اما چرا قشنگ و باحال در پایان این سلسله آموزش متوجه میشیم :) یک فهرست و راهنما کلی از این سلسله آموزش که چی قرار یادبگیریم :IntroductionHow to create thread Callable and FutureThread PoolConcurrencyExecutor frameworkFork/Join frameworkIPC MechanismIntroductionخب در این بخش از این آموزش قراره به چند سوال زیر جواب بدیم :اصلا نخ چیه ؟چرا ؟ و کجا باید از نخ استفاده کنیم ؟چه تعداد نخ مجاز است ؟جواب سوال 1 : برای توضیح فرآیند و نخ وارد جزئیات نمیشیم قطعا برای جزئیات بیشتر منابع خوب فارسی موجود استاما به بیان کلی ،نخ قسمتی از کد ما است (خودمون اون قسمتو انتخاب میکنیم ) که موازی با بقیه کد های ما اجرا می شود (شاید موازی اجرا شدن خیلی خیلی دقیق نباشد ولی در اینجا نیازی به مطرح کردن جزئیات نیست!) . زمانی که یک اپ جاوا اجرا می شود JVM میاد یک نخ اصلی (Main Thread) که برنامه ما کارشو اونجا شروع میکن و چند نخ دیگر را در حالت Daemon اجرا می کند (بعدا در مورد Daemon بحث می کنیم) از جمله این نخ ها GC یا همون آشغال جمع کن معروف در جاوا است ! در این تصویر سه نخ دیگر در کد برنامه نوشته و اجرا شده استنخ ها در طول حیات خودشون که دارن وظیفه ای برای ما انجام میدن حالت های مختلفی دارند که دونستن این حالت ها کمک بسیاری در برخورد صحیح ما با اونا میکن !!چرخه حیات نخ اما به صورت دقیق تر با این حالت ها در بخش بعدی آشنا میشیم . جواب سوال 2 : چرا ؟ و کجا باید از نخ استفاده کنیم ؟ استفاده صحیح از نخ باعث افزایش سرعت و کارایی اپ شما میش ولی مسلما همیشه اینطور نیست ! برخی از کارها ذاتا قابل تقسیم نیستن که بتونین جدا و مستقل از هم اجرا کنید پس باید مراقب باشین این هزینه سربار ایجاد نخ ارزششو داره یا نه ! معمولا کارهای I/O و همچنین برخی کارهای Cpu bound باید در نخی جداگانه اجرا بشوند و نتیجرو فقط به نخ اصلی برگردانند.جواب سوال 3 :چه تعداد نخ مجاز است ؟ تعداد نخ مجاز به پارامتر های مختلفی مثل حافظه و cpu ، jvm ، OS و... وابسته است پس تعداد مشخصی وجود ندارد ،ولی همانطور که در بالا هم گفتیم باید تعداد نخ متناسب باشد چون ایجاد هر نخ برای اپ ما سربار ایجاد می کند . این تعداد تقریبا به شکل زیر می باشد : Cpu Bound = processorCount + 1I/O Bound = processorCount * ( 1 + wait time/service time)موفق باشید :) Izax Izax Mon, 02 Sep 2019 15:41:48 +0430 https://virgool.io/@rasool/dagger-2-part-2-pbvshokyrwiq در بخش قبلی این آموزش مقدمه ای درباره تزریق وابستگی گفته شد ،و در این بخش به تشریح کتابخانه dagger2 می پردازیم .در بحث تزریق وابستگی سه بخش کلیدی داریم :بخشی که وابستگی ها را ارائه می دهد .بخشی که این وابستگی ها را مصرف می کند .بخشی که دو بخش بالا را یعنی ارائه دهنده و مصرف کننده را بهم متصل می کند .چارچوب اصلی dagger2 همین سه بخش بالا می باشند . نکته ای که باید توجه داشته باشید بسیاری از کتابخانه ها برای سهولت استفاده و تمیزتر و کمتر شدن کدها از مبحث Annotation processing استفاده می کنند و dagger هم از این قضیه مستثنا نیست ! پس برای درک واضح این کتابخانه و امثالهم آشنایی با Annotation processing بسیار مهم است .با یک سناریو کوچیک سه بخش بالارو توضیح میدم :خب یک Hero داریم که Power های مخصوص خودشو داره !! و کلاس های ما به شکل زیر می باشند :public class Main { public static void main(String[] args){ Power power = new Power(); Hero hero = new Hero(power); }public class Hero { Power power ; Hero(Power power) { this.power = power ; } }public class Power { }خب حالا میخوایم بحث تزریق وابستگی رو با dagger2 در مثال ساده بالا پیاده کنیم .بخش ارائه دهنده اشیا (ارائه دهنده وابستگی ها):این بخش یک کلاس است که با Module@ نشان گذاری می شود و داخل این کلاس متد های با مقدار برگشتی اشیا وجود دارد که با Provides@ نشان گذاری می شود ! برای مثال بالا ارائه دهنده ما به اینصورت است :import dagger.Module; import dagger.Provides; @Module public class Provider { @Provides static Power providerPower() { return new Power(); } }ارائه دهنده بالا یک متد به نام providerPower دارد که شی Power را برای ما برمی گرداند ! و کجا این شی مصرف می شود ؟! در کلاس Hero ما این شی مصرف میشود :|خب پس بخش دوم مصرف کننده :از حاشیه نویسی Inject برای مشخص کردن مصرف کننده استفاده می شود . برای مثال ما کلاس Hero ما به شکل زیر می شود :import javax.inject.Inject; public class Hero { Power power ; @Inject Hero(Power power) { this.power = power ; } } خب و در آخر نوبت به بخش سوم یعنی اتصال ارائه دهنده و مصرف کننده :این بخش یک اینترفیس است که با حاشیه نویسی Component@ مشخص می گردد و آرگومان این حاشیه نویسی کلاس ارائه دهنده ما است ! برای مثال ما این اتصال دهنده چیزی شبیه :import dagger.Component; @Component( modules = Provider.class ) public interface Connector { Hero injectPower(); }اما بعد از build کردن پروژه ،dagger میادو یک کلاس به نام(Dagger + InterfaceName) DaggerConnector درست می کند و از این به بعد ما با این کلاس سروکار داریم تا مستقیما با اشیای دیگر !!پس ما کد کلاس Main خود را به صورت زیر تغییر می دهیم :public class Main { public static void main(String[] args) { Hero hero = createHero(); } private static Hero createHero() { Connector connector = DaggerConnector.create(); return connector.injectPower(); } } تمام !اگه برای بار اول دارین DI استفاده میکنین و آشناییم با Annotation processing ندارین خیلی خیلی طبیعی که یکم گیج شده باشین ;) ولی آستینارو بالا بزنین و انجامشون بدین . در بخش بعد این آموزش همین مثال Hero با کمی کامل کردنش در اندروید استدیو پیاده می کنیم .موفق باشید :) Izax Izax Sun, 01 Sep 2019 18:51:54 +0430 https://virgool.io/@rasool/dagger-2-part-1-wqq5tsufrxge قبل از تشریح این کتابخانه لازم که دو تا سوال مهم مطرح بشه ! به چه دردی میخوره و قرار چه دردی دوا کن ؟چرا این کتابخونه !؟خب برای جواب به سوال اولمون باید سری به یکی از اصول مهندسی نرم افزار بزنیم ،اصلی به نام Inversion of control که به اختصار IoC هم میگن . اما این اصل چی میگه ؟! میگه بیا کنترل اشیا داخل برنامه و بخشی از نرم افزارو انتقال بده به بخشی مستقل و جداگانه (کنترل اشیا شمال new کردن و.. میشود) . خب اینکار چه فایده ای داره ؟جدا سازی اجرای یک بخش از پیاده سازی اون (بقیه مزایا از این مورد قابل استنتاج است)افزایش بحث ماژولاریتیآسان سازی بحث تستخب برای پیاده سازی این اصل (IoC) در نرم افزار ما ،راه های مختلفی وجود دارد از جمله :ServiceLocatorFactory PatternStrategy PatternAbstract Factory PatternTemplate MethodDependency Injectionاما ما تو این آموزش با مورد 6 یعنی Dependency Injection سروکار داریم (کتابخانه مورد نظر ما در این دسته بندی قرار دارد) . Dependency Injection به اختصار DI گوییم .کتابخانه های مختلفی برای پیاده سازی DI وجود دارد از جمله :Spring DIGoogle GuicePicoContainerJava EE6 CDIDaggerنحوه عملکرد DI در مقابل روش سنتی(بدون رعایت اصل IoC)اما نوبت میرسه به جواب سوال دوممون که در ابتدای آموزش مطرح شد ! چرا Dagger ؟ کتابخانه های مطرح شده مکانیزم های مختلفی برای پیاده سازی DI استفاده می کنند که برخی از کتابخانه ها به کمک مبحث Reflection اینکارو انجام میدن . اما Reflection چیه ؟ به طور خیلییی کوتاه قابلیتی است که به کمک اون میتونیم در زمان اجرا (Runtime) تغییراتی در کد جاوا برنامه ایجاد کنیم ! کههه یکی از مراحل اینکار Scan کردن کلاس جاواست که همین امر زمان و حافظه ای مصرف می کند در نهایت این عمل در گوشی های هوشمند که حافظه کمی دارند منظقی نیست ! (اگه متوجه نشدین اصلا مهم نیست ربطی به آموزش ما نداره ) اما Dagger با استفاده از Annotation Processing اینکارو در زمان کامپایل انجام میدهد که مشکلات سرعت پایین و اشغال حافظه در زمان اجرا را ندارد .ادامه این آموزش به 2 بخش تقسیم میشه : تشریح کتابخانه Dagger 2مثالی با Dagger 2موفق باشید . Izax Izax Fri, 16 Aug 2019 23:46:28 +0430