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

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

שאלות ותשובות לתפקיד מפתח זוטר

שאלות כלליות

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

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

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

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

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

Java Core

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

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

• בתים - מספרים שלמים הנעים בין -128 ל-127, תופס בית אחד;
• קצר - מספרים שלמים הנעים בין -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 בתים;
• ערכי אמת/שקר בוליאני , תופס 1 בייט.

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

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

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

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, בתוספת כלים נוספים שונים - מהדרים וניפוי באגים - הדרושים ליצירת יישומי Java (כולל מסמכי Java).

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

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

7. מהו bytecode?

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

8. מהן התכונות של JavaBean?

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

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

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

3. המחלקה חייבת לעקוף את המתודות equals() , hashCode() ו- toString() .

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

9. מהי OutOfMemoryError?

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

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

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

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

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

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

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

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

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

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

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

ואם ברצוננו להציג מעקב מחסנית של חריג בקונסולה:

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

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