ניתוח שאלות ותשובות מראיונות למפתח Java. חלק 1

שלום! אנשים שונים התאספו ב-JavaRush. חלקנו רק רוצים להיות מפתחי Java, משקיעים הרבה זמן ומאמץ בפיתוח, בעוד שאחרים כבר מפתחי Java. במקרה כזה או אחר צריך להיערך למבחנים – ראיונות טכניים. מבחן זה אינו קל, וחוץ מההכנה המוסרית יש צורך גם בהכנה טכנית. לאחרונה נתקלתי ברשימה גדולה של שאלות ראיונות למפתחים של Java על dou. שאלות אלו מחולקות לרמות שונות - ג'וניור, בינוני ובכיר. אל תיבהלו: לא כל השאלות קלות, אבל אלו עם כוכבית נשאלות רק לעתים רחוקות. השאלות טובות, אבל אני רוצה לנסות לענות על רובן. ברור שלא אכנס לתחום של מאמר אחד; אחרי הכל, יש שם הרבה שאלות. לכן, זו תהיה סדרה שלמה של מאמרים שיענו על שאלות כאלה. הרשה לי מיד להדגיש כמה נקודות:

1. יש מאמר מצוין עם שאלות ותשובות מובילות עבורם. חלק מהשאלות חופפות לרשימה שהוצגה לעיל (250+), כך ששאלות אלו ידלגו כדי לא לשכפל מידע שוב.

2. השאלות מוצגות באוקראינית, אך מכיוון שרוב משתתפי JavaRush דוברי רוסית (ובמידה רבה יותר גם אני), התשובות יהיו ברוסית.

3. התשובות יהיו קצרות, שכן אם תכתוב בפירוט רב, התשובות לכמה שאלות עשויות לדרוש מאמר נפרד. ובמהלך ראיונות, אין צורך בתשובות מפורטות ונפחיות כאלה, כי למראיין שלך יש רק שעה לראיין אותך בנושאים הדרושים (וכזכור, זה מספיק). למי שאוהב להעמיק, אשאיר קישורים.

אז בואו נתחיל.

שאלות ותשובות ברמת ג'וניור

בעיות כלליות

1. אילו דפוסי עיצוב אתם מכירים? ספר לנו על שתי התבניות שבהן השתמשת בעבודה שלך.

יש מגוון עצום של תבניות: אתה יכול להתחיל להכיר אותן ממאמר זה ומאמר זה. ובכן, לאלו מכם שרוצים להכיר אותם בפירוט, אני ממליץ לקרוא את הספר "הראש בראש. תבניות עיצוב" . בעזרתו תוכלו ללמוד את דפוסי העיצוב הבסיסיים ביותר בפירוט ובצורה קלה. כשמדובר בדפוסי עיצוב שתוכלו להשתמש בהם כדוגמאות בראיון, כמה שעולים בראש הם:

• Builder הוא תבנית בשימוש תכוף, אלטרנטיבה ליצירת אובייקט קלאסי;
• דפוס אסטרטגיה , המייצג מטבעו פולימורפיזם. כלומר, יש לנו ממשק אחד, אבל ההתנהגות של התוכנית תשתנה בהתאם לאיזה יישום ספציפי של ממשק זה הועבר לפונקציונליות (כעת נעשה שימוש באסטרטגיה כמעט בכל מקום ביישומי Java).

אם זה לא מספיק לכם, שימו לב ל- Spring (אם אתם כבר מכירים), כי זו פלטפורמה שלמה של מסגרות, שבתורן רצופות דפוסים למעלה ולמטה. הנה כמה דוגמאות למה שאני מדבר:

• Factory - ב- ApplicationContext (או ב-BeanFactory);
• סינגלטון - כל השעועית הן יחידות כברירת מחדל;
• פרוקסי - בעצם כל דבר באביב משתמש בדפוס זה בדרך זו או אחרת, למשל, AOP;
• שרשרת אחריות היא דפוס המבוסס על הרעיון שבו פועלת Spring Security;
• תבנית - בשימוש ב- Spring Jdbc.

Java Core

2. אילו סוגי נתונים קיימים ב-Java?

ל-Java יש סוגי נתונים פרימיטיביים:

• byte - מספרים שלמים בטווח -128 עד 127, שוקל 1 בת;
• קצר - מספרים שלמים בטווח -32768 עד 32767, שוקל 2 בתים;
• int — מספרים שלמים -2147483648 עד 2147483647, שוקל 4 בתים;
• ארוך - מספרים שלמים בטווח 9223372036854775808 עד 9223372036854775807, שוקל 8 בתים;
• float — מספרי נקודה צפה בטווח -3.4E+38 עד 3.4E+38, שוקל 4 בתים;
• כפול - מספרי נקודה צפה בטווח -1.7E+308 עד 1.7E+308, שוקל 8 בתים;
• char - תווים בודדים ב-UTF-16, שוקל 2 בתים;
• ערכים בוליאניים True/false , שוקל 1 בייט.

והתייחס לסוגי נתונים , המצביעים על אובייקטים בערימה.

3. במה שונה אובייקט מסוגי נתונים פרימיטיביים?

ההבדל הראשון: כמות הזיכרון שנכבשה: פרימיטיביים תופסים מעט מאוד, כי הם מכילים רק את הערך שלהם, בעוד שאובייקטים יכולים להכיל הרבה מאוד ערכים שונים: גם פרימיטיביים וגם הפניות לאובייקטים אחרים. ההבדל השני: ג'אווה היא שפה מכוונת עצמים, כך שהכל בה פועל באמצעות האינטראקציה בין אובייקטים, והפרימיטיביים לא משתלבים היטב (למעשה, זו הסיבה ש-Java היא לא 100% שפה מונחה עצמים). שלישית, בהמשך לשנייה: מאחר ש-Java מתמקדת באינטראקציה בין אובייקטים, לאובייקטים הללו יש מנגנונים רבים ושונים לניהולם. למשל, בנאים, שיטות, חריגים (שפועלים בעיקר על אובייקטים) וכו'. למעשה, כדי שפרימיטיביים יוכלו איכשהו להתערב (לעבוד) בסביבה מונחה עצמים זו, הומצאו עטיפות עבור טיפוסים פרימיטיביים ( מספר שלם , תו , כפול , בוליאנית ...)

4. מה ההבדל בין העברת פרמטרים לפי הפניה ולפי ערך?

שדות פרימיטיביים מאחסנים את הערך שלהם: למשל, אם קבענו int i = 9; שדה i מאחסן את הערך 9 . כאשר יש לנו הפניה לאובייקט, זה אומר שיש לנו שדה עם הפניה לאובייקט, או במילים אחרות, עם הערך של כתובת האובייקט בזיכרון.

Cat cat = new Cat();

מסתבר ששדות עם הפניה לאובייקט מאחסנים גם ערכים , ערכי כתובת זיכרון. כלומר, cat מאחסן את ערך הכתובת של האובייקט החדש Cat() בזיכרון. כאשר אנו מעבירים פרמטר למתודה, הערך שלו מועתק. במקרה של פרימיטיבי, ערך הפרימיטיבי יועתק. בהתאם, השיטה תעבוד עם עותק, שינוי אשר לא ישפיע על המקור. במקרה של סוג התייחסות, הערך של כתובת הזיכרון יועתק, בהתאמה, הכתובת תהיה זהה לאובייקט אליו היא מפנה. ואם נשנה את האובייקט באמצעות הקישור החדש הזה, הוא ישתנה עבור הישן (אחרי הכל, שניהם מצביעים על אותו אובייקט).

5. מה זה JVM, JDK, JRE?

JVM - Java Virtual Machine הוא מכונה וירטואלית המריץ קוד בייט של Java שנוצר מראש על ידי המהדר. JRE - Java Runtime Environment - היא בעצם סביבה להפעלת יישומי Java, המכילה JVM , ספריות סטנדרטיות ורכיבים נוספים להפעלת יישומונים ויישומים הכתובים בשפת התכנות Java. במילים אחרות , ה-JRE הוא חבילה של כל מה שצריך כדי להפעיל תוכנית Java מהידור, אך אינו מכיל כלים וכלי שירות כגון מהדרים או מאפי באגים לפיתוח יישומים. JDK - Java Development Kit - סט מורחב של JRE , כלומר, סביבה לא רק להפעלה, אלא גם לפיתוח יישומי Java. ה-JDK מכיל את כל מה שיש ב-JRE, בתוספת כלים נוספים שונים - מהדרים ו-debuggers הדרושים ליצירת יישומים ב-Java (מכיל גם Java docs).

6. למה להשתמש ב-JVM?

כפי שהוזכר לעיל, Java Virtual Machine היא מכונה וירטואלית המריץ קוד בייט של Java שנוצר מראש על ידי המהדר. כלומר, ה-JVM אינו מבין את קוד המקור של Java. לכן, ראשית, קומפילציה של קבצי .java , שלאחר הקומפילציה כבר יש סיומת .class ואשר מוצגים בצורה של אותו קוד בתים שה-JVM מבין. לכל מערכת הפעלה יש JVM משלה, אז לאחר שקיבל את קובצי ה-bytecode, ה-JVM מבצע אותו, ומתאים אותו למערכת ההפעלה שבה זה קורה. למעשה, בשל JVMs שונים, גרסאות JDK (או JRE) שונות עבור מערכת הפעלה שונות (כל אחת מהן דורשת JVM משלה). בואו נזכור איך הפיתוח עובד בשפות תכנות אחרות. אתה מפתח תוכנית, ואז הקוד שלה מקומפל לקוד מכונה עבור מערכת הפעלה ספציפית, ואז אתה יכול להפעיל אותו. במילים אחרות, עליך לכתוב גרסאות שונות של התוכנית עבור כל מערכת. בעוד שב-Java, הודות לעיבוד קוד כפול (קומפילציה ועיבוד של בתים של קוד JVM), אתה יכול ליהנות מהיתרונות של חוצה פלטפורמות. פעם יצרנו את הקוד, הידור מחדש לקוד byte, העברנו אותו לכל מערכת הפעלה, וה-JVM המקומי מריץ את הקוד. זהו המאפיין האגדי של Java - כתוב פעם אחת, הרץ בכל מקום . קרא עוד על כך במאמר " הידור וביצוע יישומי Java מתחת למכסה המנוע ."

7. מהו bytecode?

כפי שאמרתי למעלה, המהדר ממיר את קוד ה-Java לקוד בתים ביניים (קבצים עם סיומת .java לקבצים עם סיומת .class). Bytecode דומה במובנים רבים לקוד מכונה, רק שהוא משתמש בסט של הוראות לא ממעבד אמיתי, אלא ממעבד וירטואלי. יתרה מכך, הוא עשוי לכלול סעיפים המתמקדים בשימוש במהדר JIT, אשר מייעל את ביצוע הפקודות עבור המעבד האמיתי עליו פועלת התוכנית. קומפילציה JIT, הנקראת גם קומפילציה תוך כדי תנועה, היא טכנולוגיה המגבירה את הביצועים של תוכנית המשתמשת ב-bytecode על ידי הידור של קוד ה-byte לתוך מכונה או פורמט אחר בזמן שהתוכנית פועלת. כפי שאולי ניחשתם, ה-JVM משתמש במהדר JIT כאשר הוא מריץ קוד בתים. בואו נסתכל על דוגמה של bytecode: לא קריא מדי, נכון? ובכן, זו לא הוראה עבורנו, אלא עבור JVM. הנה מאמר שיעזור לך להבין את הנושא הזה טוב יותר.

8. מהם המאפיינים של JavaBean?

JavaBeans היא מחלקת Java עם כללים מסוימים. הנה כמה כללים לכתיבת JavaBean :

1. המחלקה חייבת להכיל בנאי גישה ציבורית ריק (ללא פרמטרים) עם משנה הגישה הציבורית . בנאי זה מאפשר ליצור אובייקט של מחלקה זו ללא בעיות מיותרות (כך שלא תהיה התעסקות מיותרת בפרמטרים).

2. השדות הפנימיים של מחלקה נגישים דרך שיטות get and set , שאמורות להיות סטנדרטיות. לדוגמה, אם השדה הוא name , אז getName ו- setName וכו'. זה, בתורו, מאפשר לכלים שונים (מסגרות) לקבוע ולעדכן באופן אוטומטי את התוכן של שעועית ללא סיבוכים.

3. המחלקה חייבת להכיל גרסאות נדחקות של מתודות equals() hashCode() ו- toString() .

4. המחלקה חייבת להיות ניתנת להמשכה, כלומר חייבת להיות לה ממשק סמן - Serializable או ליישם את ממשק Externalizable . זה הכרחי כדי שניתן יהיה לשמור, לאחסן ולשחזר את מצב השעועית בצורה מהימנה.

אתה יכול לקרוא על סוגי JavaBeans בחומר זה .

9. מה זה OutOfMemoryError?

OutOfMemoryError היא אחת משגיאות זמן הריצה הקריטיות הקשורות לפעולת ה-Java Virtual Machine (JVM). נקרא כאשר ה-JVM אינו יכול להקצות אובייקט מכיוון שאין מספיק זיכרון זמין עבורו ואוסף האשפה אינו יכול להקצות זיכרון נוסף. כמה סוגים של OutOfMemoryError :

• OutOfMemoryError: שטח ערימת Java - לא ניתן להקצות את האובייקט בערימת Java עקב חוסר זיכרון. השגיאה עלולה להיגרם כתוצאה מדליפת זיכרון או בגלל שגודל הערימה המוגדר כברירת מחדל אינו גדול מספיק עבור היישום הנוכחי.

• OutOfMemoryError: חריגה ממגבלת התקורה של GC - בשל העובדה שכמות הנתונים בקושי נכנסת לערימה, אוסף האשפה פועל כל הזמן, ותוכנת Java פועלת לאט מאוד, וכתוצאה מכך, מגבלת התקורה של אוסף האשפה חריגה והיישום קורס עם שגיאה זו.

• OutOfMemoryError: גודל המערך המבוקש חורג ממגבלת VM - מציין שהאפליקציה ניסתה להקצות זיכרון למערך שגדול מגודל הערימה, מה ששוב עשוי לנבוע מהקצאת ברירת מחדל לא מספקת של זיכרון.

• OutOfMemoryError: Metaspace - אזל השטח שהוקצה ל-metadata בערימה (מטא נתונים הם הוראות למחלקות ושיטות).

• OutOfMemoryError: בקשת בתים בגודל מסיבה. מחוץ לשטח ההחלפה - כשל מסוים אירע בעת ניסיון להקצות זיכרון מהערימה וכתוצאה מכך היה חוסר בזיכרון בערימה.

10. מהו מעקב מחסנית? איך להשיג את זה?

A Stack Trace היא רשימה של מחלקות ושיטות שנקראו עד לנקודה זו באפליקציה. אתה יכול לקרוא ל-Stack Trace בנקודה ספציפית באפליקציה כך:

StackTraceElement[] stackTraceElements =Thread.currentThread().getStackTrace();

כך נקבל מערך של רכיבי עקבות מחסנית המסודרים בסדר LIFO - Last In First Out . ב-Java, ככלל, כאשר הם מדברים על מעקב מחסנית, הם מתכוונים ל-Stack Trace שמוצג בקונסולה כאשר מתרחשת שגיאה (או חריגה). אתה יכול לקבל את עקבות החריגים של חריגים כמו זה:

StackTraceElement[] stackTraceElements;
try{
                ...
} catch (Exception e) {
   stackTraceElements = e.getStackTrace();
}

ובכן, אם אנחנו מדברים על הפלט של מעקב מחסנית החריג בקונסולה:

try{
                ...
} catch (Exception e) {
  e.printStackTrace();
}

כמו כן, אם יש לנו שגיאה, חריגה לא מסומנת או חריגה מסומנת , שאותה לא נעבד, אלא רק נעביר, אז כאשר האפליקציה קורסת נקבל אוטומטית מעקב אחר חריגים בקונסולה. דוגמה קטנה לחריגה של מעקב מחסנית במסוף: תוכל לקרוא עוד על מעקב אחר מחסנית כאן . היום נתמקד בנושא הזה...