refactor: code examples cleanup, and javadocs (#60)

Author: alxkm

src/main/java/org/alxkm/antipatterns/improperuseofthreadlocal/ThreadLocalExample.java

@@ -5,8 +5,7 @@
  * Using ThreadLocal incorrectly can lead to memory leaks or unexpected behavior.
  * ThreadLocal variables are meant to provide thread-specific storage that each thread can independently access,
  * but improper usage or not cleaning up properly can cause problems.
- *
- *
+ * <p>
  * In this example, the ThreadLocal variable is used to store and retrieve values specific to each thread.
  * However, the values are not removed after usage, which can lead to memory leaks,
  * especially in environments where threads are reused, such as in thread pools.

src/main/java/org/alxkm/antipatterns/lackofthreadsafetyinsingletons/DoubleCheckedLockingSingleton.java

@@ -3,11 +3,10 @@
 /**
  *
  * Another approach is to use double-checked locking with the volatile keyword to minimize synchronization overhead.
- *
+ * <p>
  * In this version, the volatile keyword ensures visibility of changes to the instance variable across threads,
  * while double-checked locking minimizes synchronization overhead.
  *
- *
  * */
 public class DoubleCheckedLockingSingleton {
     private static volatile DoubleCheckedLockingSingleton instance;

src/main/java/org/alxkm/antipatterns/lackofthreadsafetyinsingletons/HolderSingleton.java

@@ -1,15 +1,13 @@
 package org.alxkm.antipatterns.lackofthreadsafetyinsingletons;
 
-
 /**
+ *
  * Alternative Resolution: Initialization-on-Demand Holder Idiom
  * Another approach to implement a thread-safe singleton is the Initialization-on-Demand Holder idiom, which leverages the class loader mechanism to ensure thread safety.
  * <p>
- * <p>
  * In this version, the Holder class is loaded on the first invocation of getInstance(), ensuring thread safety through the class loader mechanism.
+ *
  **/
-
-
 public class HolderSingleton {
     /**
      * Private constructor to prevent instantiation.

src/main/java/org/alxkm/antipatterns/lackofthreadsafetyinsingletons/SafeSingleton.java

@@ -3,8 +3,7 @@
 /**
  *
  * To ensure thread safety, we can synchronize the getInstance method.
- *
- *
+ * <p>
  * In this revised example, the getInstance method is synchronized,
  * ensuring that only one instance is created even when multiple threads access the method simultaneously.
  *

src/main/java/org/alxkm/antipatterns/lackofthreadsafetyinsingletons/UnsafeSingleton.java

@@ -1,11 +1,13 @@
 package org.alxkm.antipatterns.lackofthreadsafetyinsingletons;
 
 /**
+ *
  * A common issue with singletons is the lack of proper synchronization,
  * which can lead to multiple instances being created in a multithreaded environment.
  * <p>
  * In this example, the getInstance method is not synchronized,
  * which can lead to multiple instances being created if multiple threads access the method simultaneously.
+ *
  */
 public class UnsafeSingleton {
     private static UnsafeSingleton instance;

src/main/java/org/alxkm/antipatterns/lockcontention/LockContentionExample.java

@@ -9,7 +9,6 @@
  * When multiple threads try to access these methods simultaneously, they experience high contention, reducing performance.
  *
  */
-
 public class LockContentionExample {
     private final Object lock = new Object();
     private int counter = 0;

src/main/java/org/alxkm/antipatterns/lockcontention/StampedLockExample.java

@@ -2,7 +2,6 @@
 
 import java.util.concurrent.locks.StampedLock;
 
-
 /**
  *
  * Another approach is to use StampedLock, which allows for more flexible lock handling, including optimistic reads.

src/main/java/org/alxkm/antipatterns/nonatomiccompoundactions/AtomicCompoundActionsExample.java

@@ -1,4 +1,5 @@
 package org.alxkm.antipatterns.nonatomiccompoundactions;
+
 /**
  *
  * To resolve this issue, we can synchronize the method to ensure that the compound action is atomic.

src/main/java/org/alxkm/antipatterns/nonatomiccompoundactions/AtomicIntegerExample.java

@@ -2,7 +2,6 @@
 
 import java.util.concurrent.atomic.AtomicInteger;
 
-
 /**
  * Another approach is to use the atomic classes provided by the java.util.concurrent package,
  * such as AtomicInteger, which provides atomic operations for integers.
@@ -12,6 +11,7 @@
  * that the compound action is performed atomically.
  * <p>
  * This approach leverages the atomic classes in the java.util.concurrent package to provide thread safety without explicit synchronization.
+ *
  */
 public class AtomicIntegerExample {
     private final AtomicInteger counter = new AtomicInteger();

src/main/java/org/alxkm/antipatterns/nonatomiccompoundactions/NonAtomicCompoundActionsExample.java

@@ -1,14 +1,15 @@
 package org.alxkm.antipatterns.nonatomiccompoundactions;
 
 /**
+ *
  * Non-atomic compound actions occur when compound actions (e.g., check-then-act, read-modify-write) are performed without proper synchronization,
  * leading to race conditions and incorrect results. Here's an example demonstrating this problem along with a resolution.
  * <p>
  * In this example, the incrementIfLessThan method performs a non-atomic compound action.
  * If multiple threads execute this method concurrently, they may both pass the check before either increments the counter,
  * leading to incorrect results.
+ *
  */
-
 public class NonAtomicCompoundActionsExample {
     private int counter = 0;