Οι αγαπημένες μου τεχνικές εντοπισμού σφαλμάτων Java

Αυτό το άρθρο αφορά τεχνικές που έχω χρησιμοποιήσει για τον εντοπισμό σφαλμάτων κώδικα Βάσεων διαφόρων ειδών, όπως:

  1. CodeBase με υψηλή ταυτόχρονη φύση.
  2. CodeBase με πολλές ιδιόκτητες (μη υποστηριζόμενες) βιβλιοθήκες.
  3. CodeBase με πολύ καταργημένο / ανεπιθύμητο κώδικα.
  4. CodeBase με διαρροές μνήμης.
  5. CodeBase όπου κάθε JVM μπορεί να μιλήσει σε κάθε άλλο JVM.

Ας δούμε λοιπόν ένα προς ένα.

CodeBase με υψηλή ταυτόχρονη φύση.

Μπορεί να συμβεί ότι για την εξυπηρέτηση ενός αιτήματος, το JVM χρησιμοποιεί πολλά θέματα για παράδειγμα:

Req -> tomcatThread-1 -> executorThread-2 -> BizThread-3->…`

Ας πούμε, βρίσκουμε ότι η εξαίρεση έρχεται στο BizThread-3. Τώρα ως πρόγραμμα εντοπισμού σφαλμάτων, θέλουμε να κατανοήσουμε τη ροή αιτημάτων. Ωστόσο, το stacktrace δεν θα είναι σε θέση να παρέχει την πλήρη ροή αιτημάτων (για παράδειγμα, τι συνέβη στο εκτελεστήThread-2 και τι συνέβη στο tomcatThread-1 και ούτω καθεξής).

Τεχνική 1.1: Γράψτε έναν προσαρμοσμένο java-agent που θα χρησιμοποιηθεί αποτελεσματικά log.debug()για την έναρξη και το τέλος κάθε μεθόδου συγκεκριμένων πακέτων java. Αυτό θα μας δώσει κάποια εικόνα για το τι καλείται όλα.

Τεχνική 1.2: Σε ορισμένα πλαίσια, εάν υποστηρίζονται, χρησιμοποιήστε το AOP για να κάνετε μεσολάβηση σε όλες τις μεθόδους και να προσθέσετε αποτελεσματικά log.debug().

CodeBase με πολλές ιδιόκτητες (μη υποστηριζόμενες) βιβλιοθήκες.

Μερικές φορές βρισκόμαστε σε μια κατάσταση όπου, μετά από ώρες εντοπισμού σφαλμάτων, καρφώσαμε το πρόβλημα ότι η βιβλιοθήκη xyz-gov-secret δεν λειτουργεί σωστά και αυτή η βιβλιοθήκη δεν υποστηρίζεται πλέον.

Τεχνική 2.1: Ανασηκώστε τα μανίκια σας και εγκαταστήστε το eclipse-decompilerκαι βουτήξτε στη βάση κώδικα.

CodeBase με πολύ καταργημένο / ανεπιθύμητο κώδικα.

Αυτό είναι κλασικό: μερικές φορές βρεθούμε σε μια μέθοδο 500+ γραμμών με τόνους καταργημένων αν-αλλιώς. Τώρα, πώς καταλαβαίνουμε ποια είναι η ροή κώδικα για μια συγκεκριμένη κλήση, ποια αν-αλλού πρόκειται να χρησιμοποιήσει και ποιος είναι ο νεκρός κώδικας;

Τεχνική 3.1: Μπορούμε να χρησιμοποιήσουμε ένα εργαλείο που ονομάζεται jacoco agent . Συλλέγει τις λεπτομέρειες εκτέλεσης κατά τη διάρκεια του χρόνου εκτέλεσης και μπορεί να χρωματίσει τον κώδικα στον έκλειψη.

Βασικά, είναι το ίδιο εργαλείο, που χρησιμοποιείται γενικά για την ανάλυση της κάλυψης κώδικα από το JUnit Test.

CodeBase με διαρροές μνήμης.

Κάθε προγραμματιστής έχει μια μέρα όπου, στο τοπικό τους σύστημα, όλα πάνε καλά, στην παραγωγή OutOfMemory :(

Τεχνική 4.1:Η JVM παρέχει τεχνικές για τη σύλληψη χωματερών σε περίπτωση outOfMemory.

Προσθέστε τα ακόλουθα ως όρισμα κατά την εκκίνηση του JVM

-XX: + HeapDumpOnOutOfMemoryError . Αυτό θα συλλάβει το σωρό και θα το βάλει σε ένα αρχείο, το οποίο μπορεί να χρησιμοποιηθεί για να αναλύσει τι καταναλώνει τη μνήμη.

Τεχνική 4.2: Μπορείτε επίσης να πάρετε την απόρριψη σωρού / νήμα ενός JVM που λειτουργεί χρησιμοποιώντας jProfiler / Jvisiualvm.

CodeBase όπου κάθε JVM μπορεί να μιλήσει σε κάθε άλλο JVM.

Όταν πετάτε σε ένα κατανεμημένο περιβάλλον σπαγγέτι, καθίσταται δύσκολο να εντοπίσετε τη ροή αιτημάτων.

Τεχνική 5.1: Μπορείτε να χρησιμοποιήσετε εργαλεία όπως το Wireshark . Το Wireshark καταγράφει τα δεδομένα δικτύου και τα αντιπροσωπεύει σε ένα ωραίο περιβάλλον εργασίας χρήστη. Στη συνέχεια, μπορείτε να δείτε το αίτημα / απόκριση HTTP που ρέει μέσω του συστήματος

Τιμητικές αναφορές

Τεχνική 6.1: Σε ένα μονό σπείρωμα περιβάλλον, εισάγετε σκόπιμα

try catch προκειμένου να γνωρίζουμε γρήγορα το stacktrace.

try { throw new RuntimeException(); } catch(Exception e){ e.printStackTrace(); }

Τεχνική 6.2: Χρήση σημείου διακοπής έκλειψης ή χρήση σημείου διακοπής υπό όρους.

Τεχνική 6.3: //en.wikipedia.org/wiki/Rubber_duck_debugging

Κίνητρο του άρθρου: Ομαδική μάθηση / ανταλλαγή γνώσεων.