Java 7 w akcjiJava 7 in action Wreszcie znalazłem wolną chwilę by wypróbować w praktyce nowe ficzery Java 7. Zabawy z wersją beta najnowszego jdk ułatwia NetBeans IDE 7.0 Beta 2. Do testów na pierwszy ogień poszły usprawnienia...

Readmore

Monitoring podstawowych parametrów JVM z poziomu web... Problem Monitoring podstawowych parametrów JVM z poziomu web aplikacji - przydatne zwłaszcza wtedy, gdy nasz serwer aplikacji/kontener serwletów nie pokazuje takich informacji w swojej webowej konsoli...

Readmore

Vaadin vs Richfaces i o tym co z tego wyszło [Java... Głośno ostatnio na DWorld i DZone zrobiło się o nowej odsłonie Vaadina - frameworku opartego na GWT. Nigdy wcześniej nie miałem styczności z GWT (prócz kilku tutoriali i paru hellowordów). Pracuję...

Readmore

Jak wyciągnąć kilka pierwszych wyników zapytania... [sql] -- Oracle select a.* from (select rownum row_num, t.* from t_table t ) a where a.row_num <= N -- DB2 select * from t_table fetch first 10 rows only -- Informix select...

Readmore

Vademecum IBM i oraz darmowe konto na iSeriesIBM i... Znalazłem jakiś czas temu 'hosting' oparty o iSeries, na którym można założyć sobie darmowe konto. Gdyby ktoś zatem poczuł nieodpartą pokusę pobawienia się AS/400 Green Screen, to ma taką...

Readmore

twitter

Monitoring podstawowych parametrów JVM z poziomu web aplikacji

Kategoria : java

Problem

Monitoring podstawowych parametrów JVM z poziomu web aplikacji – przydatne zwłaszcza wtedy, gdy nasz serwer aplikacji/kontener serwletów nie pokazuje takich informacji w swojej webowej konsoli i nie mamy możliwości szybkiego podpięcia się VisualVM albo JConsole (brak aktywowanego jmxremote, firewalle, czy cokolwiek innego uniemożliwiającego połączenie), a podejrzewamy że coś niedobrego może dziać się z naszą aplikacją.

Rozwiązanie

Wrzucenie prostej stronki JSP, która nam takie parametry wyświetli.

Poniżej listing (po moich drobnych modyfikacjach) zapożyczony z http://www.freshblurbs.com/explaining-java-lang-outofmemoryerror-permgen-space

Skryptlet (tak wiem, śmierdzi) użyty na tej stronie pozwala wrzucać ją do aplikacji bez potrzeby restartu serwera/redeploy aplikacji.

<%@page contentType="text/html" pageEncoding="UTF-8"%>
<%@ page import="java.util.*, java.lang.management.*" %>
<%@ taglib uri="http://java.sun.com/jstl/core_rt" prefix="c" %>
<%@ taglib uri="http://java.sun.com/jsp/jstl/fmt" prefix="fmt" %>
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN"
    	               "http://www.w3.org/TR/html4/loose.dtd">

<html>
  <head>
    <meta http-equiv="Content-Type" content="text/html; charset=UTF-8">
    <title>JVM Memory Monitor</title>
    <style type="text/css">
      td {
        text-align: right;
      }
    </style>
  </head>
<body>
  <jsp:scriptlet>
    MemoryMXBean memoryBean = ManagementFactory.getMemoryMXBean();
    pageContext.setAttribute("memoryBean", memoryBean, PageContext.PAGE_SCOPE);

    List poolBeans = ManagementFactory.getMemoryPoolMXBeans();
    pageContext.setAttribute("poolBeans", poolBeans, PageContext.PAGE_SCOPE);
  </jsp:scriptlet>

  <h3>Total Memory</h3>
  <table border="1" width="100%">
    <tr>
      <th>usage</th>
      <th>init</th>
      <th>used</th>
      <th>committed</th>
      <th>max</th>
    </tr>
    <tr>
      <td style="text-align: left">Heap Memory Usage</td>
      <td><fmt:formatNumber value="${pageScope.memoryBean.heapMemoryUsage.init / (1024 * 1024)}" maxFractionDigits="1"/> MB</td>
      <td><fmt:formatNumber value="${pageScope.memoryBean.heapMemoryUsage.used / (1024 * 1024)}" maxFractionDigits="1"/> MB</td>
      <td><fmt:formatNumber value="${pageScope.memoryBean.heapMemoryUsage.committed / (1024 * 1024)}" maxFractionDigits="1"/> MB</td>
      <td><fmt:formatNumber value="${pageScope.memoryBean.heapMemoryUsage.max / (1024 * 1024)}" maxFractionDigits="1"/> MB</td>
    </tr>
    <tr>
      <td style="text-align: left">Non-heap Memory Usage</td>
      <td><fmt:formatNumber value="${pageScope.memoryBean.nonHeapMemoryUsage.init / (1024 * 1024)}" maxFractionDigits="1"/> MB</td>
      <td><fmt:formatNumber value="${pageScope.memoryBean.nonHeapMemoryUsage.used / (1024 * 1024)}" maxFractionDigits="1"/> MB</td>
      <td><fmt:formatNumber value="${pageScope.memoryBean.nonHeapMemoryUsage.committed / (1024 * 1024)}" maxFractionDigits="1"/> MB</td>
      <td><fmt:formatNumber value="${pageScope.memoryBean.nonHeapMemoryUsage.max / (1024 * 1024)}" maxFractionDigits="1"/> MB</td>
    </tr>
  </table>

  <h3>Memory Pools</h3>
  <table border="1" width="100%">
    <tr>
      <th>Name</th>
      <th>Usage</th>
      <th>Init</th>
      <th>Used</th>
      <th>Committed</th>
      <th>Max</th>
    </tr>
    <c:forEach var="bean" items="${pageScope.poolBeans}">
      <tr>
        <td style="text-align: left"><c:out value="${bean.name}" /></td>
        <td style="text-align: left">Memory Usage</td>
        <td><fmt:formatNumber value="${bean.usage.init / (1024 * 1024)}" maxFractionDigits="1"/> MB</td>
        <td><fmt:formatNumber value="${bean.usage.used / (1024 * 1024)}" maxFractionDigits="1"/> MB</td>
        <td><fmt:formatNumber value="${bean.usage.committed / (1024 * 1024)}" maxFractionDigits="1"/> MB</td>
        <td><fmt:formatNumber value="${bean.usage.max / (1024 * 1024)}" maxFractionDigits="1"/> MB</td>
      </tr>
      <tr>
        <td></td>
        <td style="text-align: left">Peak Usage</td>
        <td><fmt:formatNumber value="${bean.peakUsage.init / (1024 * 1024)}" maxFractionDigits="1"/> MB</td>
        <td><fmt:formatNumber value="${bean.peakUsage.used / (1024 * 1024)}" maxFractionDigits="1"/> MB</td>
        <td><fmt:formatNumber value="${bean.peakUsage.committed / (1024 * 1024)}" maxFractionDigits="1"/> MB</td>
        <td><fmt:formatNumber value="${bean.peakUsage.max / (1024 * 1024)}" maxFractionDigits="1"/> MB</td>
      </tr>
    </c:forEach>
  </table>
</body>
</html>

Efekt poniżej:

To rozwiązanie tak mi się spodobało, że z rozpędu napisałem sobie to samo w Richfaces. Strona odświeża się automatycznie co zadany przedział czasu (w ms). Wykorzystanie Ajax Push/Poll nie powala na pewno z punktu widzenia wydajności, jest natomiast rozwiązaniem banalnym do zaimplementowania:

<html xmlns:ui="http://java.sun.com/jsf/facelets"
    xmlns:h="http://java.sun.com/jsf/html"
    xmlns:f="http://java.sun.com/jsf/core"
    xmlns:a4j="http://richfaces.org/a4j"
    xmlns:rich="http://richfaces.org/rich">

<head>
    <title>JVM Memory Monitor</title>
</head>

<body>
    <a4j:region>
        <h:form>
            <a4j:poll id="poll" interval="#{jvmPerformanceManager.interval}" enabled="#{jvmPerformanceManager.pollEnabled}" reRender="polledPanel, poll"/>
        </h:form>
    </a4j:region>
    <h:form prependId="false">
        <h:panelGrid id="polledPanel" columns="1">
            <h3>Total Memory</h3>
            <rich:dataTable value="2" style="text-align: right">
                <f:facet name="header">
                    <rich:columnGroup>
                        <rich:column>
                            <h:outputText value="Name" />
                        </rich:column>
                        <rich:column>
                            <h:outputText value="Init" />
                        </rich:column>
                        <rich:column>
                            <h:outputText value="Used" />
                        </rich:column>
                        <rich:column>
                            <h:outputText value="Committed" />
                        </rich:column>
                        <rich:column>
                            <h:outputText value="Max" />
                        </rich:column>
                    </rich:columnGroup>
                </f:facet>
                <rich:column>
                    <h:outputText value="Heap Memory Usage" />
                </rich:column>
                <rich:column>
                    <h:outputText
                        value="#{jvmPerformanceManager.memoryBean.heapMemoryUsage.init / (1024 * 1024)}">
                        <f:convertNumber pattern="#,##0.0 MB" locale="US" />
                    </h:outputText>
                </rich:column>
                <rich:column>
                    <h:outputText
                        value="#{jvmPerformanceManager.memoryBean.heapMemoryUsage.used / (1024 * 1024)}">
                        <f:convertNumber pattern="#,##0.0 MB" locale="US" />
                    </h:outputText>
                </rich:column>
                <rich:column>
                    <h:outputText
                        value="#{jvmPerformanceManager.memoryBean.heapMemoryUsage.committed / (1024 * 1024)}">
                        <f:convertNumber pattern="#,##0.0 MB" locale="US" />
                    </h:outputText>
                </rich:column>
                <rich:column>
                    <h:outputText
                        value="#{jvmPerformanceManager.memoryBean.heapMemoryUsage.max / (1024 * 1024)}">
                        <f:convertNumber pattern="#,##0.0 MB" locale="US" />
                    </h:outputText>
                </rich:column>
                <rich:column breakBefore="true">
                    <h:outputText value="Non-heap Memory Usage" />
                </rich:column>
                <rich:column>
                    <h:outputText
                        value="#{jvmPerformanceManager.memoryBean.nonHeapMemoryUsage.init / (1024 * 1024)}">
                        <f:convertNumber pattern="#,##0.0 MB" locale="US" />
                    </h:outputText>
                </rich:column>
                <rich:column>
                    <h:outputText
                        value="#{jvmPerformanceManager.memoryBean.nonHeapMemoryUsage.used / (1024 * 1024)}">
                        <f:convertNumber pattern="#,##0.0 MB" locale="US" />
                    </h:outputText>
                </rich:column>
                <rich:column>
                    <h:outputText
                        value="#{jvmPerformanceManager.memoryBean.nonHeapMemoryUsage.committed / (1024 * 1024)}">
                        <f:convertNumber pattern="#,##0.0 MB" locale="US" />
                    </h:outputText>
                </rich:column>
                <rich:column>
                    <h:outputText
                        value="#{jvmPerformanceManager.memoryBean.nonHeapMemoryUsage.max / (1024 * 1024)}">
                        <f:convertNumber pattern="#,##0.0 MB" locale="US" />
                    </h:outputText>
                </rich:column>

                <f:facet name="footer">
                    <rich:columnGroup>
                        <rich:column>Last actualization date</rich:column>
                        <rich:column colspan="4">
                            <h:outputText value="#{jvmPerformanceManager.lastActualization}">
                                <f:convertDateTime pattern="yyyy-MM-dd HH:mm:ss" timeZone="#{jvmPerformanceManager.timeZone}"/>
                            </h:outputText>
                        </rich:column>
                    </rich:columnGroup>
                </f:facet>
            </rich:dataTable>

            <h3>Memory Pools</h3>
            <rich:dataTable var="poolBean" value="#{jvmPerformanceManager.poolList}"
                style="text-align: right">
                <f:facet name="header">
                    <rich:columnGroup>
                        <rich:column>
                            <h:outputText value="Name" />
                        </rich:column>
                        <rich:column>
                            <h:outputText value="Usage" />
                        </rich:column>
                        <rich:column>
                            <h:outputText value="Init" />
                        </rich:column>
                        <rich:column>
                            <h:outputText value="Used" />
                        </rich:column>
                        <rich:column>
                            <h:outputText value="Committed" />
                        </rich:column>
                        <rich:column>
                            <h:outputText value="Max" />
                        </rich:column>
                    </rich:columnGroup>
                </f:facet>
                <rich:column rowspan="2">
                    <h:outputText value="#{poolBean.name}" />
                </rich:column>
                <rich:column>
                    <h:outputText value="Memory" />
                </rich:column>
                <rich:column>
                    <h:outputText value="#{poolBean.usage.init / (1024 * 1024)}">
                        <f:convertNumber pattern="#,##0.0 MB" locale="US" />
                    </h:outputText>
                </rich:column>
                <rich:column>
                    <h:outputText value="#{poolBean.usage.used / (1024 * 1024)}">
                        <f:convertNumber pattern="#,##0.0 MB" locale="US" />
                    </h:outputText>
                </rich:column>
                <rich:column>
                    <h:outputText value="#{poolBean.usage.committed / (1024 * 1024)}">
                        <f:convertNumber pattern="#,##0.0 MB" locale="US" />
                    </h:outputText>
                </rich:column>
                <rich:column>
                    <h:outputText value="#{poolBean.usage.max / (1024 * 1024)}">
                        <f:convertNumber pattern="#,##0.0 MB" locale="US" />
                    </h:outputText>
                </rich:column>
                <rich:column breakBefore="true">
                    <h:outputText value="Peak" />
                </rich:column>
                <rich:column>
                    <h:outputText value="#{poolBean.peakUsage.init / (1024 * 1024)}">
                        <f:convertNumber pattern="#,##0.0 MB" locale="US" />
                    </h:outputText>
                </rich:column>
                <rich:column>
                    <h:outputText value="#{poolBean.peakUsage.used / (1024 * 1024)}">
                        <f:convertNumber pattern="#,##0.0 MB" locale="US" />
                    </h:outputText>
                </rich:column>
                <rich:column>
                    <h:outputText
                        value="#{poolBean.peakUsage.committed / (1024 * 1024)}">
                        <f:convertNumber pattern="#,##0.0 MB" locale="US" />
                    </h:outputText>
                </rich:column>
                <rich:column>
                    <h:outputText value="#{poolBean.peakUsage.max / (1024 * 1024)}">
                        <f:convertNumber pattern="#,##0.0 MB" locale="US" />
                    </h:outputText>
                </rich:column>
            </rich:dataTable>

            <h:panelGrid columns="2">
                <h:column>
                    <a4j:commandButton id="controlBtn"
                        value="#{jvmPerformanceManager.pollEnabled?'Stop':'Start'}" reRender="polledPanel, poll">
                    <a4j:actionparam name="polling" value="#{!jvmPerformanceManager.pollEnabled}"
                        assignTo="#{jvmPerformanceManager.pollEnabled}" />
                    </a4j:commandButton>
                </h:column>
                <h:column>
                    <a4j:outputPanel style="display: inline" rendered="#{!jvmPerformanceManager.pollEnabled}">
                        <h:outputText value=" with " />
                        <h:inputText value="#{jvmPerformanceManager.interval}">
                            <f:validateLongRange minimum="500" />
                        </h:inputText>
                        <h:outputText value=" ms interval." />
                    </a4j:outputPanel>
                </h:column>
            </h:panelGrid>
        </h:panelGrid>
    </h:form>
</body>
</html>
package info.ludera.helper;

import java.io.Serializable;
import java.lang.management.ManagementFactory;
import java.lang.management.MemoryMXBean;
import java.lang.management.MemoryPoolMXBean;
import java.util.Calendar;
import java.util.Date;
import java.util.List;
import java.util.TimeZone;
import javax.faces.bean.ManagedBean;
import javax.faces.bean.SessionScoped;
import javax.faces.event.ActionEvent;

@ManagedBean(name="jvmPerformanceManager")
@SessionScoped
public class JvmPerformanceManager implements Serializable {

    private MemoryMXBean memoryBean;

    private List<MemoryPoolMXBean> poolList;

    private Boolean pollEnabled = true;

    /**
     * Interval in milliseconds. Default 10s.
     */
    private Long interval = 10*1000l;

    private String timeZone;

    public JvmPerformanceManager() {
        getActualMemoryInfo(null);
        timeZone = readDefaultHostTimeZone();
    }

    private String readDefaultHostTimeZone() {
        return TimeZone.getDefault().getID();
    }

    public void getActualMemoryInfo(ActionEvent actionEvent) {
        memoryBean = ManagementFactory.getMemoryMXBean();
        poolList = ManagementFactory.getMemoryPoolMXBeans();
    }

    public MemoryMXBean getMemoryBean() {
        return memoryBean;
    }

    public List<MemoryPoolMXBean> getPoolList() {
        return poolList;
    }

    public Boolean getPollEnabled() {
        return pollEnabled;
    }

    public void setPollEnabled(Boolean pollEnabled) {
        this.pollEnabled = pollEnabled;
    }

    public Long getInterval() {
        return interval;
    }

    public void setInterval(Long interval) {
        this.interval = interval;
    }

    public Date getLastActualization() {
        return Calendar.getInstance().getTime();
    }

    public String getTimeZone() {
        return timeZone;
    }
}

Efekt:

Jestem obecnie, jak pewnie wielu, na etapie rozpoznawania nowości w Java EE 6. Treningowo, postanowiłem zatem napisać ten sam JVM Monitor z wykorzystaniem Asynchronious Processing Support z Servlets 3.0 – także wkrótce rozwinięcie tematu.

Singleton z double-checked locking oraz problem z wielowątkowością w TestNG

Kategoria : java

Wyczytałem ostatnio w mądrych książkach (tej i tej), że synchronizacja singletonów na poziomie całej metody getInstance może w środowisku wielowątkowym znacznie (25%) spowolnić pobieranie instancji obiektu przechowywanego przez owy singleton. W polskiej wikipedii ktoś napisał, że synchronizacja ta może obniżyć wydajność (w stosunku do metody niesynchronizowanej) o czynnik 100 lub więcej – szczerze, nie rozumiem co oznacza rzeczony ‚czynnik 100’…

W przypadku, gdy wydajność ma dla nas kluczowe znaczenie, do tworzenia singletonów zalecano stosowanie wzorca double-checked locking (blokada z podwójnym zatwierdzaniem). Postanowiłem więc sprawdzić doświadczalnie jak w rzeczywistości wygląda spadek wydajności metod synchronizowanych. Napisałem więc trzy singletony:

tradycyjny

package info.ludera.SingletonPerformance.action.impl;

import info.ludera.SingletonPerformance.action.TestSingleton;

/**
 * Singleton z ZAWSZE synchronizowaną metodą {@link SimpleSingleton#getInstance()}
 * @author darekl
 *
 */
public class SimpleSingleton extends TestSingleton {

	/**
	 * Jedyna instancja obiektu {@link SimpleSingleton}
	 */
	private static SimpleSingleton instance;

	/**
	 * Konstruktor domyślny
	 */
	private SimpleSingleton() {
		super();
	}

	/**
	 * Zwraca instancję obiektu  {@link SimpleSingleton}
	 * @return
	 */
	public static synchronized SimpleSingleton getInstance() {

		if (instance == null) {
			instance = new SimpleSingleton();
		}
		return instance;
	}
}

i dwie różne implementacje double-checked locking:

„podstawowa”

package info.ludera.SingletonPerformance.action.impl;

import info.ludera.SingletonPerformance.action.TestSingleton;

/**
 * Singleton z synchronizowaną metodą {@link SimpleSingleton#getInstance()}. Synchronizacja aktywna jest tylko przy pierwszym uruchomieniu tej metody.
 * @author darekl
 *
 */
public class ThreadSaveSingleton extends TestSingleton {

	/**
	 * Jedyna instancja obiektu {@link SimpleSingleton}
	 */
	private volatile static ThreadSaveSingleton instance = null;

	/**
	 * Konstruktor domyślny
	 */
	private ThreadSaveSingleton() {
		super();
	}

	/**
	 * Zwraca instancję obiektu  {@link SimpleSingleton}
	 * @return
	 */
	public static ThreadSaveSingleton getInstance() {

		if (instance == null) {
			synchronized (ThreadSaveSingleton.class) {
				if (instance == null) {
					instance = new ThreadSaveSingleton();
				}
			}
		}
		return instance;
	}
}

i „rozszerzona

package info.ludera.SingletonPerformance.action.impl;

import info.ludera.SingletonPerformance.action.TestSingleton;

/**
 * Singleton z synchronizowaną metodą {@link SimpleSingleton#getInstance()}. Synchronizacja aktywna jest tylko przy pierwszym uruchomieniu tej metody.
 * @author darekl
 *
 */
public class AdvancedThreadSaveSingleton extends TestSingleton {

	/**
	 * Jedyna instancja obiektu {@link SimpleSingleton}
	 */
	private volatile static AdvancedThreadSaveSingleton instance = null;

	/**
	 * Konstruktor domyślny
	 */
	private AdvancedThreadSaveSingleton() {
		super();
	}

	/**
	 * Zwraca instancję obiektu  {@link SimpleSingleton}
	 * @return
	 */
	public static AdvancedThreadSaveSingleton getInstance() {

		AdvancedThreadSaveSingleton result = instance;
		if (result == null) {
			synchronized (AdvancedThreadSaveSingleton.class) {
				result = instance;
				if (result == null) {
					instance = result = new AdvancedThreadSaveSingleton();
				}
			}
		}
		return result;
	}
}

Przetestowałem ich działanie poniższym testem dla różnej ilości wątków (100-100000):

package info.ludera.SingletonPerformance.test;

...

public class FabricMultiThreadSingletonTest extends AbstractSingletonTest {

	@DataProvider
	public Object[][] ValidJavaVersion() {

		return new Object[][]{
				{ 5 }
		};
	}

	/**
	 * Ilość iteracji
	 */
	protected static Long testCounter;

	/**
	 * Prefix nazwy wątku
	 */
	protected static String threadNamePrefix = "Thread_";

	@BeforeClass
	@Parameters(value="repetitionQuantity")
	public void setTestCounter(long repetitionQuantity) {
		testCounter = repetitionQuantity;
	}

	@Test
	public void getSimpleSingletonNTimes() {

		for (long i=0; i<testCounter; i++) {
			SingletonFactory simpleSingletonFactory = new SimpleSingletonFactory(threadNamePrefix + i);
			simpleSingletonFactory.start();
		}
	}

	@Test(dataProvider = "ValidJavaVersion")
	public void getThreadSaveSingletonNTimes(final int javaVersion) {

		//Assert.assertTrue((Integer.parseInt("" + System.getProperty("java.version").charAt(2)) >= javaVersion), "This test is avialable only with Java 5 or above!");

		for (long i=0; i<testCounter; i++) {
			SingletonFactory threadSaveSingletonFactory = new ThreadSaveSingletonFactory(threadNamePrefix + i);
			threadSaveSingletonFactory.start();
		}
	}

	@Test(dataProvider = "ValidJavaVersion")
	public void getAdvencedThreadSaveSingletonNTimes(final int javaVersion) {

		//Assert.assertTrue((Integer.parseInt("" + System.getProperty("java.version").charAt(2)) >= javaVersion), "This test is avialable only with Java 5 or above!");

		for (long i=0; i<testCounter; i++) {
			SingletonFactory advancedThreadSaveSingletonFactory = new AdvancedThreadSaveSingletonFactory(threadNamePrefix + i);
			advancedThreadSaveSingletonFactory.start();
		}
	}
}

I rzeczywiście. Czasowe wyniki działania tych testów, dla różnej ilości iteracji, rozchodziły się w słuszną stronę. Wraz ze wzrostem iteracji, SimpleSingleton działał coraz wolniej w stosunku do wersji z double-checked locking. Testy przeprowadzałem na JDK 1.6.0_16 oraz JDK 1.5.0_22. Nie testowałem wydajności na Java 1.4. Istnieje bowiem prawdopodobieństwo wystąpienia problemu błędnej implementacji volatile. Oto przykładowe wyniki dla 10000 iteracji na JDK 1.6:

getSimpleSingletonNTimes - 1624ms
getThreadSaveSingletonNTimes - 1209ms
getAdvencedThreadSaveSingletonNTimes - 1153ms

To nie wszystko. Po zastanowieniu, doszedłem do wniosku, że użycie wzorca fabryki do takich teścików to przerost formy nad treścią. Stwierdziłem więc, że wykorzystam wielowątkowości z TestNG.

oto test:

package info.ludera.SingletonPerformance.test;

...

import org.testng.annotations.Test;

/**
 * Test wydajności synchronizacji singletonów {@link info.ludera.SingletonPerformance.test.helper.SimpleSingletonFactory} i {@link info.ludera.SingletonPerformance.test.helper.ThreadSaveSingletonFactory}
 * @author darekl
 *
 */
public class MultiThreadSingletonTest extends AbstractSingletonTest {

	@Test(threadPoolSize=1000, invocationCount = 1000)
	public void getSimpleSingleton() {

		SimpleSingleton.getInstance();
	}

	@Test(dataProvider = "ValidJavaVersion", threadPoolSize=1000, invocationCount = 1000)
	public void getThreadSaveSingleton(final int javaVersion) {

		//Assert.assertTrue((Integer.parseInt("" + System.getProperty("java.version").charAt(2)) >= javaVersion), "This test is avialable only with Java 5 or above!");

		ThreadSaveSingleton.getInstance();
	}

	@Test(dataProvider = "ValidJavaVersion", threadPoolSize=1000, invocationCount = 1000)
	public void getAdvencedThreadSaveSingleton(final int javaVersion) {

		//Assert.assertTrue((Integer.parseInt("" + System.getProperty("java.version").charAt(2)) >= javaVersion), "This test is avialable only with Java 5 or above!");

		AdvancedThreadSaveSingleton.getInstance();
	}
}

i wyniki (tym razem dla 1000 wątków):

getSimpleSingletonNTimes - 110ms
getThreadSaveSingletonNTimes - 97ms
getAdvencedThreadSaveSingletonNTimes - 100ms
getSimpleSingleton - 716ms
getThreadSaveSingleton - 2050ms
getAdvencedThreadSaveSingleton - 2079ms

Zastanawiające. Dlaczego trzy ostatnie testy (te dopisane powyżej) nie układają się tak jak te poprzednie, gdzie wielowątkowość napisałem ręcznie? Dlaczego widać tak duże różnice w wydajności? Przyznam szczerze, że z wielowątkowości w TestNG korzystam po praz pierwszy, czy ktoś bardziej doświadczony w tym temacie, mógłby mi wyjaśnić w czym tkwi problem na który się natknąłem i co robię źle?

Pobierz projekt eclipse (wymagania: Maven2 lub Eclipse z pluginami: m2eclipse i TestNG)

PS. Apropos optymalizacji kodu pod względem jego wydajności, polecam ten artykuł. Po jego przeczytaniu nasunęła mi się analogia dotycząca RDBMS i hintów oraz przesiadki z optymalizatorów regułowych na kosztowe ;)

package info.ludera.SingletonPerformance.action.impl;

import info.ludera.SingletonPerformance.action.TestSingleton;

/**
* Singleton z ZAWSZE synchronizowaną metodą {@link SimpleSingleton#getInstance()}
* @author darekl
*
*/
public class SimpleSingleton extends TestSingleton {

/**
* Jedyna instancja obiektu {@link SimpleSingleton}
*/
private static SimpleSingleton instance;

/**
* Konstruktor domyślny
*/
private SimpleSingleton() {
super();
}

/**
* Zwraca instancję obiektu {@link SimpleSingleton}
* @return
*/
public static synchronized SimpleSingleton getInstance() {

//System.out.println(„SimpleSingleton.getInstance start for ” + Thread.currentThread().getName());
if (instance == null) {
instance = new SimpleSingleton();
}
//System.out.println(„SimpleSingleton.getInstance stop for ” + Thread.currentThread().getName());
return instance;
}
}

JSF – automatyczna zamiana null na 0 lub pusty string

Kategoria : java

Myślalem, że JSF nie ma już przede mną większych tajemnic, gdy w projekcie objawił się nam następujący błąd:

JSF domyślnie z automatu zamienia formularzowe puste inputy na odpowiadające im 0 lub puste stringi. Inaczej mówiąc jeśli użytkownik do takiego inputTextu nic nie wpisze to referencja age zamiast być pusta (null) wskazywać będzie na 0.

<h:inputText id="age"
value="#{exampleManager.age}" converter="IntegerConverter" />

Gdyby age było Stringiem, wówczas JSF przypisałby pod niego „”.

Rozwiązanie tego ‚problemu’ okazało się trywialne choć dziwne (stąd ta notka). Należało zmienić domyślną wartość flagi Tomcata COERCE_TO_ZERO poprzez ustawienie odpowiedniego parametru uruchomieniowego:

-Dorg.apache.el.parser.COERCE_TO_ZERO=false

Domyślna wartość COERCE_TO_ZERO ustawiona jest na true. Oczywiście można tego dokonać również z poziomu kodu aplikacji – jak dla mnie rozwiązanie takie jest dużo bardziej elastyczne i eleganckie:

System.getProperties().
put("org.apache.el.parser.COERCE_TO_ZERO", "false");

Projekt w którym objawił się ten problem pracuje na JBossie (posiadającym w sobie Tomcata), jak aplikacja ta zachowała by się na innych serwerach aplikacyjnych i jak wówczas poradzić sobie z opisywanym ‚wymuszaniem’ – kiedyś może się dowiem…

JavaBlackBelt

Kategoria : Cv

Od 27 lipca zacząłem bawić się w zdobywanie kolejnych pasów na JavaBlackBelt. W skrócie chodzi o zdawanie egzaminów dotyczących technologii około javowych, za które uzyskujemy punkty przeliczane następnie na pasy al’a karate. Strasznie wkręca :)

Naj(gorsze)lepsze jest to, iż by podejść do wybranego egzaminu trzeba mieć na jego zdanie odpowiednią ilość punków (odpowiednik pieniędzy), którą zdobywa się poprzez aktywność w tej społeczności – dodawanie, poprawianie, komentowanie egzaminów i pytań. Im więcej dajesz siebie społeczności, tym bardziej możesz z jej dobrodziejstwa korzystać – majstersztyk jeśli chodzi o serwisy społecznościowe. Od paru dni zatem, w różnych okolicznościach, rodzą mi się więc w głowie kolejne pytania, które mógłbym dodać do serwisu.

Jeśli chodzi o merytoryczną zawartość egzaminów to pytania przechodzą przez dość krytyczne sito użytkowników – nie ma więc głupich pytań w stylu WTF. W trakcie zdawania egzaminu – a pytania nierzadko są obiektywnie trudne – można korzystać z Google, IDE, książek itp, jedynym ograniczeniem jest czas. Egzaminy sprawdzają więc praktyczną umiejętność programowania, czyli to o co powinno w egzaminach na certyfikaty chodzić.

Podsumowując moją podnietę w temacie JavaBlackBelt, jest to idealne połączenie przyjemnego z pożytecznym. Poniżej mój aktualny pasiasty dorobek:

WSDL2JAVA w Ant

Kategoria : java

Poniżej przykład uruchomienia generatora kodu Java dla zadanego WSDL (Axis2 WSDL2JAVA):

Z kosoli:

$PROJEKT/scr> WSDL2Java -uri http://localhost:8080/axis2/services/WebServiceExample?wsdl -d adb -s -S .

Ant:


<project name="WsExampleClient" default="dist" basedir=".">
<property name="location.dir.src" value="."/>
<path id="axis2.classpath">
<fileset dir="D:\libs\axis2-1.4.1\lib">
<include name="**/*.jar" />
</fileset>
</path>
<target name="codegen">
<taskdef name="axis2-wsdl2java" classname="org.apache.axis2.tool.ant.AntCodegenTask"
classpathref="axis2.classpath" />
<axis2-wsdl2java
wsdlfilename="http://localhost:8080/axis2/services/WebServiceExample?wsdl"
output="${location.dir.src}" />
</target>
</project>

Parametry axis2.classpath i wsdlfilename ustawiamy swoje. Sorkiewicz za brak wcięć ;)

Java – wyrażenia regularne – vademecum

Kategoria : java

Ile razy piszę jakiegoś bardziej skomplikowanego regexpa w Javie, tyle razy muszę posiłkować się Google, bo nie mogę zapamiętać wszystkich składniowych fanaberii twórców wyrażeń regularnych.

Wygląda na to że ta stronka zawiera wszystko w jednym miejscu, nic tylko wydrukować i położyć na biurku albo powiesić na wewnętrznej stronie drzwi firmowej toalety :)

http://mindprod.com/jgloss/regex.html

PS. Jeśli trafiłeś tutaj z wyszukiwarki z chęcią nauczenia się wyrażeń regularnych, zacznij od tego artykułu.

Jak pobrać ilość wierszy z Result Set

Kategoria : java

Wydawało by się, że będzie to banalne i ograniczy się do wywołania na rzecz naszego ResultSeta metody getRowsCount() lub podobnej.

Niestety nie jest to takie oczywiste. ResultSetMetaData, czyli obiekt zawierające przeróżne informacje na temat samego ResultSeta, również nie posiada odpowiedniej metody.

Wymyśliłem więc takie cuś. Wygląda pokracznie, żeby nie powiedzieć paskudnie… ale działa i dobrze się ma :)

try {
    // scrollowalny ResultSet
    Statement stmt = 
        connection.createStatement(
        ResultSet.TYPE_SCROLL_INSENSITIVE,
        ResultSet.CONCUR_READ_ONLY);
    ResultSet resultSet = 
        stmt.executeQuery("SELECT * FROM t_t1");

    resultSet.last();
    int rowCount = resultSet.getRow();
    resultSet.beforeFirst();
    
    // teraz mozna dalej uzywac
    // do woli ResultSeta
    ...
} catch(SQLException e) {
    e.printStackTrace();
    // lub jakies bardziej eleganckie:
    log.error(e.getMessage());
}

Sun Certified Java Programmer (SCJP) – jak zdać

Kategoria : Cv, java

Szczęśliwie jestem już Sun Certified Java Programmer (SCJP), więc postanowiłem podzielić się z innym jak go zdać, a wbrew pozorom nie jest to takie hopaj siup, nawet dla osób które kodują w Javie od jej początków.

Egzamin bowiem polega na zamienieniu się osoby egzaminowanej w kompilator i udzielaniu odpowiedzi na pytania typu: czy dany kod się skompiluje (jeżeli nie to dlaczego) a jeśli tak to co będzie wynikiem jego działania. Jednym słowem podchwytliwy test wielokrotnego wyboru.

Po pierwsze sugestia: dobrze zastanów się i oceń swoje możliwości dotyczące czasu jaki przeznaczysz na naukę oraz swoich dotychczasowych umiejętności z zakresu Javy. Jeśli Twój voucher traci już termin ważności a Ty z nauką jesteś w lesie, zastanów się z jakiej edycji Javy chcesz być egzaminowany. Moja sytuacja była właśnie taka, że od poinformowania mnie o tym że mam zostać SCJP do terminu upłynięcia ważności vouchera miałem około miesiąca na przygotowanie się. Zdecydowałem się więc pójść na łatwiznę i zdawać Javę 1.4. Egzaminy różnią się tematyką, zakresem materiału, ilością pytań oraz wymaganą do zdania ilością udzielenia pozytywnych odpowiedzi. Java 1.4 jest obiektywnie patrząc prostsza do nauczenia się i zdania.

Poniżej linki do wymagań egzaminacyjnych:

Sun Certified Programmer for the Java Platform, Standard Edition 6 (CX-310-065) – NEW!

Upgrade Exam: Sun Certified Programmer for the Java Platform, Standard Edition 6 (CX-310-066) – NEW!

Sun Certified Programmer for the Java Platform, Standard Edition 5.0 (CX-310-055)

Upgrade Exam: Sun Certified Programmer for the Java Platform, Standard Edition 5.0 (CX-310-056)

Materiały do nauki:

  • tuż przed egzaminem: Egzaminy Whizlabs – bez przerobienia tego do egzaminu nie podchodź!

Swój egzamin zdawałem w Krakowie, w ośrodku ABC Data przy Długiej 48 i bardzo go polecam. Co najważniejsze są stosunkowo krótkie kolejki, radzę jednak umówić się telefonicznie na ponad miesiąc przed, by nie stresować się, że voucher przepadnie albo będziemy zmuszeni podróżować po Polsce w poszukiwaniu inszego ośrodka z wolnymi miejscami (przeegzaminuje cię każdy ośrodek który chwali się Prometric, cokolwiek by to było :) ).

Przebieg egzaminu jest nagrywany, mamy do dyspozycji tabliczkę formatu A4 i marker, co zwłaszcza przy egzaminie w edycji 1.4 może być kłopotliwe (rozpisywanie kolejności operatorów itp). Wynik egzaminu znany jest zaraz po jego zakończeniu, na okoliczność czego otrzymujemy papierowy raport z przebiegu egzaminu, z wyszczególnionymi ocenami z poszczególnych jego części – rozdziałów. Właściwy certyfikat, z gadżetami które prezentuję poniżej i zgodą na używanie logo SCJP otrzymamy na wskazany adres.

Aha, bardzo ważna sprawa: Przed rozpoczęciem egzaminu jesteśmy przepytywani jak oceniamy swoje przygotowanie z poszczególnych zagadnień do egzaminu. Ma to chyba wpływ na rodzaj losowanych pytań, ja zachowawczo przy wszystkich zagadnieniach postawiłem ocenę Good i tematykę pytań miałem raczej równo zbalansowaną. Kolega z którym zdawalem egzamin, kiepsko ocenił się z wątków i mial właśnie więcej z nich pytań – szczęśliwie i tak dobrze zdał. Także nie wiem jaki dokładny wpływ na pytania ma ta ankieta, sugeruję uważać:)

Jeśli nie dostaliście od swojego pracodawcy vouchera na zdawanie egzaminu, bądź jesteście studentami poszukajcie kontaktu do Uczelnianych Ambasadorów Firmy Sun – studenci mają olbrzymie zniżki na egzaminy (byćmoże to będzie dla kogoś motywacja na zapisanie się na kolejne studia w swoim życiu;)). Z tego miejsca pozwalam sobie zacytować Ambasadora Sun z jednej z krakowskich uczelni:

Są zniżki dla studentów i pracowników uczelni. Cena egzaminu ze zniżką wynosi około 200zł (40€ z marginesem) zamiast mniej więcej 800zł.

Dostępne są następujące egzaminy:

212-019 Sun Certified Associate for Java Platform, Standard Edition, Exam Version 1.0

212-035 Sun Certified Programmer for the Java 2 Platform 1.4

212-055 Sun Certified Programmer for the Java 2 Platform, Standard Edition 5.0

212-056 Sun Certified Programmer for J2SE 5.0 – UPGRADE EXAM

212-065 Sun Certified Programmer for the Java 2 Platform, Standard Edition 6.0

212-066 Sun Certified Upgrade Exam for the Sun Certified Java Programmer, SE 6.0

212-083 Sun Certified Web Component Developer for the Java Platform, Enterprise Edition 5

212-105 Sun Certified Solaris Associate

212-200 Sun Certified System Administrator for Solaris 10 OS, Part 1 Exam

212-202 Sun Certified System Administrator for Solaris 10 OS, Part 2 Exam

212-302 Sun Certified Network Administrator for Solaris 10 OS Exam

Data stworzenia tego posta zobowiązuje, zatem obiecuję sobie w 2009 roku podejść do SCWCD i zrobić upgrade swojego SCJP do wersji 1.6. Czy się uda? Jak mawiają starzy górale „We will see”… :)