For many, the world of Java is shrouded in mystery and endeavor. One such endeavor is garbage collection. There is many a viewpoint on garbage collection – whether it is good or bad, when is it needed, how often should it run, how to tune garbage collection operation, how to know when it is not operating as expected, and so on. In this educational post, we will try to clear the air on Java garbage collection and make it easy for developers and administrators to deal with it.

A thread, in the context of Java, is the path followed when executing a program. All Java programs have at least one thread, known as the main thread, which is created by the Java Virtual Machine (JVM) at the program’s start, when the main() method is invoked with the main thread. In Java, creating a thread is accomplished by implementing an interface and extending a class. Every Java thread is created and controlled by the java.lang.Thread class.

There are multiple reasons why Java and the Java Virtual Machine-based languages are very popular among developers. A rich ecosystem with lots of open-source frameworks that can be easily incorporated and used is only one of them. The second, in my opinion, is the automatic memory management with a powerful garbage collector. The Java garbage collector, or in short, the GC, takes care of cleaning up the unused bits and pieces.

Today it is even easier to capture logs in your Java applications. Developers can get more data with their application logs using a new version of the Cloud Logging client library for Java. The library populates the current executing context implicitly with every ingested log entry. Read this if you want to learn how to get HTTP requests and tracing information and additional metadata in your logs without writing a single line of code.

In December, information security researchers discovered a serious vulnerability in the popular open-source logging library, Log4j. If exploited, this vulnerability, known as Log4Shell, could allow malicious attackers to execute code remotely on any targeted computer. Millions of computers use Log4j. According to one study, 93% of all cloud environments are affected by the vulnerability.

All the applications that you’re trying to execute require memory. It doesn’t matter if the application was developed using assembly language. Or if you used a low-level programming language like C or a language compiled to a bytecode like Java. Running the application requires memory for the code itself, the variables, and the data that the code processes. Depending on your usage, the memory requirements will vary.

The Log4Shell (CVE-2021-44228) zero day vulnerability in the Java logging framework Log4j (versions 2.0 to 2.14.1) was revealed on December 9, 2021. The Apache Foundation assigned the maximum CVSS score of 10 to Log4Shell, as millions of servers and potentially, billions of devices came under risk. Security professionals around the world began patching the vulnerability, and scanning their systems to rule out any potential breach.

Examining Java logs is usually the quickest way to figure out why your application is experiencing trouble, so it's critical to have it in place. Best practices for Java logging can help you troubleshoot and address issues before they affect your users or business. In many circumstances, this entails utilizing a Java logging tool capable of automating your processes and delivering faster and more accurate results than manual logging.

A summary of the Log4j vulnerability, and key takeaways for SREs.