آموزش ۵۰۰+ سوال و جواب مصاحبه اسپرینگ بوت (Spring Boot) ۲۰۲۶ - آخرین آپدیت

در ادامه، توضیحات این دوره به صورت بهینه شده برای سئو گوگل و یودمی ارائه شده است. لحن این مطالب مشابه یک مصاحبه‌کننده فنی با تجربه است تا از هرگونه کلی‌گویی‌های AI فاصله بگیرد.

پوشش دقیق حوزه‌های آزمون

این مخزن آزمون‌ها تعادلی بین معماری عملیاتی، استانداردهای کدنویسی و امنیت سیستم ایجاد کرده است. توزیع مباحث دقیقاً مطابق با موضوعات متوسط و پیشرفته‌ای است که در مصاحبه‌های فنی واقعی با آن‌ها روبرو می‌شوید:

• اسپرینگ بوت پایه (۲۰٪):تحلیل مکانیسم‌های Auto-configuration، انوتیشن‌های شرطی سفارشی (@ConditionalOnProperty, @ConditionalOnClass)، سرولت کانتینرهای داخلی و ساختارهای پیکربندی خارجی پیچیده از طریق Multi-profile و YAML.

• REST APIها و میکروسرویس‌ها (۱۸٪):معماری سرویس‌های RESTful سطح Production، طراحی قراردادها، HATEOAS، ردیابی توزیع شده (Distributed Tracing)، مکانیسم‌های Service Discovery و الگوهایی مانند Circuit Breaker یا API Gateway.

• دیتابیس و Persistence (۱۵٪):نگاشت مدل‌های شیء-رابطه‌ای با Spring Data JPA و Hibernate. بررسی عمیق چرخه حیات Entityها، نگاشت روابط، تله‌های Lazy Fetching، سطوح جداسازی تراکنش‌ها، پیکربندی‌های Propagation و گلوگاه‌های عملکردی.

• امنیت و احراز هویت (۱۲٪):امن‌سازی سرویس‌های بک‌اند با فیلترهای پیشرفته Spring Security. پیکربندی Providerهای احراز هویت سفارشی، پیاده‌سازی معماری توکن JWT بدون وضعیت و ساختار سرورهای منابع OAuth2 سازمانی.

• تست و دیباگ (۱۰٪):نوشتن تست‌های جامع با @SpringBootTest، @WebMvcTest و @DataJpaTest. تسلط بر Stubbing و Mocking با Mockito، دیباگ ساختاری، مدیریت خطاهای متمرکز (@RestControllerAdvice) و پروفایل‌های لاگ سفارشی.

• استقرار و مانیتورینگ (۸٪):بهره‌گیری از Spring Boot Actuator برای متریک‌ها و تله‌متری زنده. ایجاد نقاط انتهایی امن برای بررسی سلامت، پیکربندی ادغام با Prometheus/Grafana و مدیریت Docker Buildهای چند مرحله‌ای.

• بهترین متدها و الگوهای طراحی (۷٪):اعمال الگوهای طراحی (Factory, Strategy, Proxy) در کانتینر IoC، اجرای استانداردهای کدنویسی و مراحل ریفکتورینگ بر اساس توسعه تست‌محور (TDD).

• مباحث پیشرفته (۱۰٪):پرداختن به معماری‌های پیچیده سازمانی با استفاده از کامپوننت‌های Spring Cloud، استراتژی‌های کشینگ توزیع شده (Redis)، تردهای اجرای تسک‌های Asynchronous و ارکستراسیون چند سرویسه.

درباره این دوره

پشت سر گذاشتن مصاحبه‌های پیشرفته جاوا یا توسعه‌دهنده بک‌اند، نیازمند درکی است که بسیار فراتر از دانستن نحوه ایجاد یک پروژه ساده است. تیم‌های مهندسی مدرن به دنبال متخصصانی هستند که دقیقاً بدانند هنگام بوت‌استرپ شدن یک اپلیکیشن اسپرینگ چه اتفاقی در پشت صحنه می‌افتد، Thread Poolها چگونه تراکنش‌های سنگین دیتابیس را مدیریت می‌کنند و چگونه می‌توان از میکروسرویس‌ها در برابر شکست‌های زنجیره‌ای سیستم محافظت کرد. من این مخزن آزمون ۵۵۰ سوالی را دقیقاً برای شبیه‌سازی سوالات سخت و مورد-محور (Case-study) شرکت‌های برتر تکنولوژی طراحی کرده‌ام.

به جای پرسیدن سوالات ساده تعریف‌گونه، این دوره چالش‌های واقعی محیط Production را ارائه می‌دهد: زنجیره‌های فیلتر Spring Security که اشتباه پیکربندی شده‌اند، نشت در Connection Poolهای دیتابیس، مشکلات حافظه در Lazy Loading و قطع شدن Circuit Breakerها در کلاسترهای میکروسرویس. هر سوال دارای یک تحلیل فنی جامع و چند لایه است. من منطق اصلی پشت انتخاب معماری درست را توضیح داده و شفاف می‌کنم که چرا گزینه‌های جایگزین باعث کاهش عملکرد اپلیکیشن یا ایجاد حفره‌های امنیتی می‌شوند. اگر می‌خواهید عمق مهندسی خود را افزایش دهید، دانش فعلی‌تان از فریمورک اسپرینگ را ارزیابی کنید یا مطمئن شوید که در اولین تلاش از فیلترهای فنی عبور می‌کنید، این بانک سوالات دقیقاً همان تمرین واقعی را برای شما فراهم می‌کند.

پیش‌نمایش نمونه سوالات

این سه نمونه سوال با کیفیت بالا را بررسی کنید تا ببینید توضیحات در این دوره چگونه ساختار یافته‌اند.

سوال ۱: تشخیص‌های Auto-Configuration و نتایج ارزیابی شرط‌ها

در هنگام مقداردهی اولیه یک اپلیکیشن پیچیده، یک Bean سفارشی که در کلاس پیکربندی شما تعریف شده، لود نمی‌شود. شما مشکوک به تداخل با یک کلاس auto-configuration پیش‌فرض هستید. اسپرینگ بوت پیکربندی‌های شرطی را در پشت صحنه چگونه پردازش می‌کند و کدام روش به شما اجازه می‌دهد ماتریس تصمیم‌گیری را به طور شفاف بررسی کنید؟

• الف) از یک فاز مقداردهی اولیه تک مرحله‌ای استفاده می‌کند که در آن Beanهای معمولی اولویت دارند و می‌توانید با دیباگر مراحل تعریف Bean Factory را دنبال کنید.

• ب) انواع @Conditional را در دو فاز مشخص در زمان رفرش Application Context ارزیابی می‌کند و شما می‌توانید نتایج را از طریق فلگ --debug یا نقطه انتهایی Actuator /conditions بررسی کنید.

• ج) ابتدا auto-configuration را قبل از خواندن کلاس‌های پیکربندی تعریف شده توسط کاربر پردازش می‌کند، لذا باید کلاس‌ها را دستی از طریق تنظیمات application property استثنا کنید.

• د) از رهگیری ساختاری Aspect-Oriented برای تطبیق فایل‌های پیکربندی استفاده می‌کند و شما باید Stack Traceهای کنسول را برای یافتن خطاهای ثبت Bean بررسی کنید.

• ه) تطبیق شرط‌ها را از طریق پلاگین‌های خارجی در زمان Build اجرا می‌کند، بنابراین بررسی پویا شکست‌های ثبت Bean در زمان اجرا غیرممکن است.

• و) درخت وابستگی‌ها را در یک فایل سیستمی رمزنگاری شده دنبال می‌کند که برای رمزگشایی در فازهای اجرای سرور، به ابزارهای دسترسی مدیریت خاص نیاز دارد.

پاسخ صحیح و توضیح:

• پاسخ صحیح: ب

• دلیل صحت:اسپرینگ بوت از یک سیستم پردازش کانتکست دو مرحله‌ای استفاده می‌کند. ابتدا پیکربندی‌های صریح کاربر را ثبت می‌کند و سپس auto-configurationها را. شرط‌هایی مانند @ConditionalOnMissingBean به صورت پویا ارزیابی می‌شوند. اجرای اپلیکیشن با فلگ --debug یا فراخوانی نقطه انتهایی Actuator /conditions گزارشی کامل از دلیل تطبیق یا عدم تطبیق پیکربندی‌ها به شما می‌دهد.

• دلیل عدم صحت گزینه‌های دیگر:

  • گزینه الف غلط است:قرار دادن Breakpoint در کل تعاریف Bean خسته‌کننده است و قوانین ارزیابی دقیق مورد استفاده در Condition Matcherها را فاش نمی‌کند.

  • گزینه ج غلط است:Auto-configuration بعداز پیکربندی کاربر اجرا می‌شود. همین زمان‌بندی است که اجازه می‌دهد Beanهای سفارشی شما جایگزین Beanهای پیش‌فرض شوند.

  • گزینه د غلط است:اسپرینگ بوت برای مدیریت پروفایل‌های پیکربندی از مکانیسم‌های ثبت شرطی استاندارد استفاده می‌کند، نه زیرساخت پیچیده AOP.

  • گزینه ه غلط است:تمام منطق‌های شرطی در زمان شروع اپلیکیشن به صورت پویا ارزیابی می‌شوند، نه در زمان کامپایل یا Build.

  • گزینه و غلط است:هیچ فایلی رمزنگاری نمی‌شود؛ وضعیت کاملاً در فضای حافظه ApplicationContext مدیریت می‌شود.

سوال ۲: مدیریت پیشرفته تراکنش‌های JPA و سناریوهای شکست در Propagation

یک متد سرویس در اسپرینگ بوت را در نظر بگیرید که با @Transactional(propagation = Propagation.REQUIRED) علامت‌گذاری شده است. در داخل این متد، یک متد کمکی (Helper) محلی در همان کلاس سرویس فراخوانی می‌شود. این متد کمکی صراحتاً با @Transactional(propagation = Propagation.REQUIRES_NEW) انوتیشن شده است. اگر متد کمکی یک Runtime Exception پرتاب کند، نتیجه دقیق در مورد مرزهای تراکنش دیتابیس چه خواهد بود؟

• الف) متد کمکی یک تراکنش فیزیکی مجزا در دیتابیس ایجاد می‌کند که به طور مستقل Rollback می‌شود و تراکنش والد بدون تغییر باقی می‌ماند.

• ب) سیستم خطای کامپایلر می‌دهد زیرا نمی‌توانید قوانین Propagation متفاوت را در یک کلاس لایه سرویس تعریف کنید.

• ج) اسپرینگ به دلیل محدودیت‌های داخلی Proxy، دستور REQUIRES_NEW را نادیده می‌گیرد و کد را در تراکنش والد اجرا می‌کند و هر دو عملیات را Rollback می‌کند.

• د) تراکنش والد بلافاصله وضعیت فعلی خود را Commit می‌کند و سپس اجرا را به بلوک تراکنش متد فرزند جدید منتقل می‌کند.

• ه) اپلیکیشن با خطای Thread Deadlock کرش می‌کند زیرا Connection Pool دیتابیس نمی‌تواند دو اتصال را به یک ترد اجرای یکسان اختصاص دهد.

• و) متد تودرتو کاملاً Proxy کانتینر را دور می‌زند و داده‌ها را بدون هیچ کنترل تراکنشی مستقیماً در دیتابیس می‌نویسد.

پاسخ صحیح و توضیح:

• پاسخ صحیح: ج

• دلیل صحت:اسپرینگ به طور پیش‌فرض از AOP مبتنی بر Proxy برای مدیریت تراکنش‌ها استفاده می‌کند. وقتی یک متد، متد دیگری را در هماننمونه کلاس فراخوانی می‌کند (Intra-class call)، این فراخوانی Wrapper پروکسی خارجی را دور می‌زند. در نتیجه، انوتیشن @Transactional روی متد کمکی نادیده گرفته می‌شود. هر دو متد در داخل تراکنش والد اجرا می‌شوند، به این معنی که یک Runtime Exception در متد کمکی، کل تعامل با دیتابیس را Rollback می‌کند.

• دلیل عدم صحت گزینه‌های دیگر:

  • گزینه الف غلط است:تراکنش‌های مجزا تنها در صورتی ایجاد می‌شدند که متد کمکی در یک Bean تزریق شده مجزا قرار داشت تا اجرا از طریق فریمورک پروکسی اسپرینگ عبور کند.

  • گزینه ب غلط است:تعریف این انوتیشن‌ها سینتکس معتبری دارد و بدون هیچ خطایی کامپایل می‌شود.

  • گزینه د غلط است:REQUIRES_NEW تراکنش‌های فعال را متوقف (Pause) می‌کند، نه اینکه آن‌ها را زودتر Commit کند. با این حال، این مکانیسم به دلیل Intra-class call هرگز فعال نمی‌شود.

  • گزینه ه غلط است:Deadlock زمانی رخ می‌دهد که منابع در چندین ترد قفل شوند. یک تک ترد که در یک پروکسی دور زده شده اجرا می‌شود، باعث Deadlock نمی‌شود.

  • گزینه و غلط است:عملیات کاملاً کنترل‌های تراکنشی را دور نمی‌زند؛ بلکه همچنان تحت کانتکست تراکنش فعال متد والد اجرا می‌شود.

سوال ۳: سفارشی‌سازی زنجیره فیلتر Spring Security و استخراج JWT بدون وضعیت

شما در حال پیاده‌سازی یک زیرساخت API بدون وضعیت (Stateless) هستید که توسط توکن‌های احراز هویت JWT محافظت می‌شود. یک فیلتر سفارشی که از OncePerRequestFilter ارث‌بری می‌کند در کلاس پیکربندی شما تزریق شده است. اگر این فیلتر را به اشتباه با استفاده از دستور .addFilterBefore() نسبت به UsernamePasswordAuthenticationFilter استاندارد ثبت کنید، زیرسیستم امنیتی به درخواست‌های API احراز نشده چگونه واکنش نشان می‌دهد؟

• الف) زیرسیستم امنیتی نقص توکن را در زمان کامپایل اولیه شناسایی کرده و شما را مجبور به اصلاح ترتیب فیلترها می‌کند.

• ب) اپلیکیشن فیلتر سفارشی را کاملاً نادیده می‌گیرد و تمام ترافیک را بدون اعتبارسنجی مستقیماً به نقاط انتهایی عمومی هدایت می‌کند.

• ج) لایه امنیتی ابتدا فیلتر سفارشی را اجرا می‌کند. اگر تجزیه توکن یا پر کردن Security Context نادیده گرفته شود، اجرا به فیلترهای بعدی می‌رود که درخواست را به دلیل نبود احراز هویت مناسب رد می‌کنند.

• د) کانتینر در اولین درخواست یک استثنای Illegal Filter پرتاب کرده و تمام قوانین مسیریابی امنیتی وب فعال را کاملاً غیرفعال می‌کند.

• ه) سرور درخواست را رهگیری کرده و یک حلقه ریدایرکت (Redirect Loop) خودکار بین صفحه لاگین و نقطه انتهایی هدف ایجاد می‌کند.

• و) زنجیره فیلتر کاملاً می‌شکند و به هر ترافیک ورودی اجازه می‌دهد بدون هیچ بررسی امنیتی به داده‌های محافظت شده دسترسی داشته باشد.

پاسخ صحیح و توضیح:

• پاسخ صحیح: ج

• دلیل صحت:فیلترهای JWT سفارشی قبل از UsernamePasswordAuthenticationFilter قرار می‌گیرند تا توکن‌ها را استخراج کرده و SecurityContextHolder را زودتر پر کنند. اگر یک درخواست ورودی فاقد توکن باشد، فیلتر سفارشی شما باید صرفاً filterChain.doFilter(request, response) را صدا بزند تا درخواست را به جلو ببرد. سپس فیلترهای پایین‌دست یک کانتکست امنیتی خالی می‌بینند و درخواست غیرمجاز را رد می‌کنند.

• دلیل عدم صحت گزینه‌های دیگر:

  • گزینه الف غلط است:انتخاب ترتیب فیلترها در زمان اجرا (Runtime) ارزیابی می‌شود، بنابراین باعث خطای Build یا کامپایل نمی‌شود.

  • گزینه ب غلط است:سیستم همچنان فیلتر سفارشی را پردازش می‌کند؛ آن را نادیده نمی‌گیرد یا مسیریابی عمومی را باز نمی‌کند.

  • گزینه د غلط است:ثبت فیلترها از طریق addFilterBefore یک روش استاندارد است و باعث کرش کردن runtime کانتینر نمی‌شود.

  • گزینه ه غلط است:حلقه‌های ریدایرکت در سیستم‌های form-login با پیکربندی غلط رخ می‌دهند، نه به طور بومی در نقاط انتهایی API بدون وضعیت.

  • گزینه و غلط است:زنجیره فیلتر دست‌نخورده باقی می‌ماند. اگر درخواستی در فیلتر سفارشی شما از احراز هویت عبور کند، فیلترهای بعدی مانند FilterSecurityInterceptor همچنان آن را شناسایی کرده و دسترسی را مسدود می‌کنند.

چه انتظاراتی داشته باشید

• به آزمون‌های مصاحبه‌ای خوش آمدید تا شما را برای تست‌های عملی سوالات اسپرینگ بوت آماده کنیم.

• می‌توانید آزمون‌ها را هر چند بار که بخواهید تکرار کنید.

• این یک بانک سوالات بسیار بزرگ و اورجینال است.

• در صورت داشتن سوال، از پشتیبانی مدرسان بهره‌مند می‌شوید.

• هر سوال دارای یک توضیح دقیق و جامع است.

• کاملاً با اپلیکیشن یودمی در موبایل سازگار است.

امیدواریم تا اینجا متقاعد شده باشید! سوالات بسیار بیشتری در داخل دوره وجود دارد.