Top 10 causes of performance issues in Java

 

 

Cause #1: The JVM spends more time performing garbage collection due to

• improper Garbage Collection (GC) configuration. E.g. Young generation being too small.
• Heap size is too small (use -Xmx). The application footprint is larger than the allocated heap size.
• Wrong use of libraries. For example, XML based report generation using DOM parser as opposed to StAX for large reports generated concurrently by multiple users. 
• Incorrectly creating and discarding objects without astutely reusing them with a flyweight design pattern or proper caching strategy.
• Other OS activities like swap space or networking activity during GC can make GC pauses last longer. 
• Any explicit System.gc( ) from your application or third party modules.

Run your JVM with GC options such as 

• -verbose:gc (print the GC logs) 
• -Xloggc: (comprehensive GC logging) 
• -XX:+PrintGCDetails (for more detailed output) 
• -XX:+PrintTenuringDistribution (tenuring thresholds)

to understand the GC patterns.

Cause #2: Bad use of application algorithms, strategies, and queries. For example

• SQL queries with Cartesian joins.
• SQL queries invoking materialized views
• Regular expressions with back tracking algorithms.
• Inefficient Java coding and algorithms in frequently executed methods leading to death by thousand cuts.
• Excessive data caching or inappropriate cache refresh strategy.
• Overuse of pessimistic locking as opposed to favoring optimistic locking.

Cause #3:  Memory leaks due to

• Long living objects having reference to short living objects, causing the memory to slowly grow. For example, singleton classes referring to short lived objects. This prevents short-lived objects being garbage collected.
• Improper use of thread-local variables. The thread-local variables will not be removed by the garbage collector as long as the thread itself is alive. So, when threads are pooled and kept alive forever, the object might never be removed by the garbage collector.
• Using mutable static fields to hold data caches, and not explicitly clearing them. The mutable static fields and collections need to be explicitly cleared.
• Objects with circular or bidirectional references.
• JNI memory leaks.

Cause #4: Poor integration with external systems without proper design & testing.

• Not properly deciding between synchronous vs asynchronous calls to internal and external systems. Long running tasks need to be performed asynchronously. 
• Not properly setting service timeouts and retries or setting service time out values to be too high.
• Not performing non happy path testing and not tuning external systems to perform efficiently.
• Unnecessarily making too many network round trips.

Cause #5: Improper use of Java frameworks and libraries.

• Using Hibernate without properly understanding lazy loading versus eager fetching and other tuning capabilities.
• Not inspecting the SQLs internally generated by your ORM tools like Hibernate.
• Using the deprecated libraries like Vector or Hashtable as opposed to the new concurrent libraries that allow concurrent reads.
• Using blocking I/O where the the Java NIO (New I/O) with non blocking capability is favored. 
• Database deadlocks due bad schema design or  application logic.
• Spinning out your own in efficient libraries as opposed to favoring proven frameworks.

Cause #6: Multi-threading issues due to to deadlocks, thread starvation, and thread contention. 

• Using coarse grained locks over fine grained locks. 
• Not favoring concurrent utility classes like  ConcurrentHashMap, CopyOnWriteArrayList, etc. 
• Not favoring lock free algorithms.

Cause #7: Not managing and recycling your non memory resources properly.

• Not pooling your valuable non memory resources like sockets, connections, file handles, threads, etc. 
• Not properly releasing your resources back to its pool after use can lead to resource leaks and performance issues. 
• Use of too many threads leading to more CPU time being used for context switching. 
• Hand rolling your own pooling without favoring proven libraries. 
• Using a third-party library with resource leaks.
• Load balancers leaking sockets.

Cause #8: Bad infrastructure designs and bugs.

• Databases tables not properly partitioned. 
• Not enough physical memory on the box.
• Not enough hard disk space.
• Bad network latency. 
• Too many nodes on the server.
• Load balancers  not working as intended and not performing outage testing.
• Not tuning application servers properly.
• Not performing proper capacity planning.
• router, switch, and DNS server failures. 

Cause #9: Excessive logging and not using proper logging libraries with capabilities to control log levels like debug, info, warning, etc. System.out.println(….) are NOT ALLOWED. Favor asynchronous logging in mission critical and high volume applications like trading systems. 

Cause #10: Not conducting performance tests, not monitoring the systems, and lack of documentation and performance focus from the start of the project.

• Not performing performance test plans with tools like JMeter with production like data prior to each deployment.
• Not monitoring the systems for CPU usage, memory usage, thread usage, garbage collection patterns, I/O, etc on an on going basis. 
• Not defining SLA’s (Service Level Agreements) from the start in the non-functional specification.
• Not maintaining proper performance benchmarks to be compared against with the successive releases and performance tests.
• Not looking for performance issues in peer code reviews or not having code reviews at all.

Migrate the xml to a @Configuration

 @Configuration Implement in Spring

Migrate the xml to a @Configuration in a few steps:

1. Create a @Configuration annotated class:

   @Configuration
   public class MyApplicationContext {
   
   }

2. For each <bean> tag create a method annotated with @Bean:

   @Configuration
   public class MyApplicationContext {
   
     @Bean(name = "someBean")
     public SomeClass getSomeClass() {
       return new SomeClassImpl(someInterestingProperty); // We still need to inject someInterestingProperty
     }
   
     @Bean(name = "anotherBean")
     pubic AnotherClass getAnotherClass() {
       return new AnotherClassImpl(getSomeClass(), beanFromSomewhereElse); // We still need to inject beanFromSomewhereElse
     }
   }

3. In order to import beanFromSomewhereElse we need to import it's definition. It can be defined in an XML and the we'll use @ImportResource:

   @ImportResource("another-application-context.xml")
   @Configuration
   public class MyApplicationContext {
     ...  
   }

   If the bean is defined in another @Configuration class we can use the @Import annotation:

   @Import(OtherConfiguration.class)
   @Configuration
   public class MyApplicationContext {
     ...
   }

4. After we imported other XMLs or @Configuration classes, we can use the beans they declare in our context by declaring a private member to the @Configuration class as follows:

   @Autowired
   @Qualifier(value = "beanFromSomewhereElse")
   private final StrangeBean beanFromSomewhereElse;

   Or use it directly as parameter in the method which defines the bean that depends on this beanFromSomewhereElse using @Qualifier as follows:

   @Bean(name = "anotherBean")
   pubic AnotherClass getAnotherClass(@Qualifier (value = "beanFromSomewhereElse") final StrangeBean beanFromSomewhereElse) {
     return new AnotherClassImpl(getSomeClass(), beanFromSomewhereElse);
   }

5. Importing properties is very similar to importing bean from another xml or @Configuration class. Instead of using @Qualifier we'll use @Value with properties as follows:

   @Autowired
   @Value("${some.interesting.property}")
   private final String someInterestingProperty;

   This can be used with SpEL expressions as well.
6. In order to allow spring to treat such classes as beans containers we need to mark this in our main xml by putting this tag in the context:

   <context:annotation-config/>

   You can now import @Configuration classes exactly the same as you would create a simple bean:

   <bean class="some.package.MyApplicationContext"/>

   There are ways to avoid spring XMLs altogether but they are not in the scope of this answer. You can find out one of these options in the blog post on which I'm basing my answer (disclaimer - the post is written by me).

---

The advantages and disadvantages of using this method

Basically I find this method of declaring beans much more comfortable than using XMLs due to a few advantages I see:

1. Typos - @Configuration classes are compiled and typos just won't allow compilations
2. Fail fast (compile time) - If you forget to inject a bean you'll fail on compile time and not on run-time as with XMLs
3. Easier to navigate in IDE - between constructors of beans to understand the dependency tree.
4. Possible to easily debug configuration startup

The disadvantages are not many as I see them but there are a few which I could think of:

1. Abuse - Code is easier to abuse than XMLs
2. With XMLs you can defined dependencies based on classes that are not available during compile time but are provided during run-time. With @Configuration classes you must have the classes available at compile time. Usually that's not an issue, but there are cases it may be.

Bottom line: It is perfectly fine to combine XMLs, @Configuration and annotations in your application context. Spring doesn't care about the method a bean was declared with.

Security Best Pratices for Java Developer

Security is playing vital role in your  project . While devloping our application following areas we have to verify .

Area	What to look for
SQL injection	A SQL injection attack occurs when untrusted input can modify the semantics of a SQL query in unexpected ways. As you review the code, make sure that the SQL queries are parameterized and that any input used in a SQL query is validated.
Cross-site scripting	Cross-site scripting occurs when an attacker manages to inject script code into an application so that script code is echoed back and executed in the security context of the application. This can allow an attacker to steal user information, including forms data and cookies. This vulnerability can be present whenever a Web application echoes unfiltered user input back to Web content.
Data access	Look for improper storage of database connection strings and proper use of authentication to the database.
Input/data validation	Look for client-side validation that is not backed by server-side validation, poor validation techniques, and reliance on file names or other insecure mechanisms to make security decisions.
Authentication	Look for weak passwords, clear-text credentials, overly long sessions, and passwords or secrets being stored in session data
Authorization	Look for failure to limit database access, inadequate separation of privileges, and mechanisms to work around authorization checks.
Sensitive data	Look for mismanagement of sensitive data by disclosing secrets in error messages, code, memory, files, or the network.
Hard-coded secrets	Look for hard-coded secrets in code by looking for variable names such as "key", "password", "pwd", "secret", "hash", and "salt".
Poor error handling	Look for functions with missing error handlers or empty catch blocks.
Too verbose error handling	Look for functions which do data integrity validation before checking data access authorization. Such error handling may reveal too much information about what is in the database to an unauthorized user.
Undocumented public interfaces	Most undocumented interfaces should not be in the application, and they are almost never given the same level of design and test scrutiny as the rest of the code. If an operation is exposed as a public interface, check that it actually required.
Threading problems	Check for race conditions and deadlocks, especially in static methods and constructors.
Unreleased resources	Look for allocation of resources for a request that are not released when the request is serviced.
Assigning resources before authentication	Look for allocation of resources prior to authentication.

MergeSort implemented in Java

private static void merge(int[] source, int[] buffer, int startingIndex, int count) {
    int lowerIndex = startingIndex;
    int lowerBound = startingIndex + count / 2;
    int upperIndex = lowerBound;
    int upperBound = startingIndex + count;

    for(int i = startingIndex ; i < upperBound ; i++){
        if(upperIndex >= upperBound ){
          System.arraycopy(source, lowerIndex , buffer, i, i - startingIndex );
          return;
        }
        if(lowerIndex >= lowerBound ){
          System.arraycopy(source, upperIndex , buffer, i, i - startingIndex );
          return;
        }
        buffer[i] = source[lowerIndex] < source[upperIndex] ? source[lowerIndex++] : source[upperIndex++]
    }
}

Merge Sort recurrently   implemented by  Divide and conquer Algorithm.