A short introduction on why memory usage might not be what you expect it to be and tools for going deeper. Different ways for acquiring memory snapshots and how to examine them with MAT.
Vår Java VM: Ett långsamt mellanlager och nödvändigt ont eller har vi någon nytta av den sett till prestanda? Vad gör den med allt minne? Varför sysslar den till och med med “de-optimization”?!
Jag och några kollegor har precis varit på ett fullspäckat JFokus i Stockholm. I år (precis som förra året) höll hela spektaklet hus i Stockholm Waterfront Congress Centre, som ligger mitt i smeten, endast ett stenkast från centralen. JFokus är (om du inte visste det redan) en tre-dagars konferens med stort fokus på Java och allt som snurrar runt Java. Första dagen är en tutorial-dag där fokus läggs på längre sessioner och mer övningar i ett fåtal ämnen. Jag hade inte möjlighet att vara med på detta i år, utan fokuserade mer på dag 2 och 3 så är fullspäckade av väldigt intressanta 15-50 minuterspresentationer.
Även om vi hade en monter på andra våningen (eller var det tredje våningen?) så spenderade jag största delen av min tid på att gå på sessionerna/presentationerna. Konferensen har inga officiella spår (eller fokusområden), men det märktes att vissa ämnen var hetare än andra. Funktionell programmering, concurrency, nitty-gritty-detaljer om JVM:en, persistens i Java och CQRS summerar de områden som jag stötte på under mina två dagar där.
Tyvärr så gick presentationer i fyra rum samtidigt, så jag hann ju inte med att se allt jag ville =( Jag tänkte här gå igenom de presentationer som jag gick på och lite tankar omkring dem. Detta inlägg innehåller första dagens presentationer, så dag 2 kommer i ett annat inlägg.
Den första och enda presentationen jag inte skrev några anteckningar om. Kan bero på att jag inte riktigt förstod vad allt det han pratade om gick ut på. Eller för att det var tidigt på morgonen och kaffet inte riktigt kickat igång min hjärna. I alla fall så var presentationen väldigt seg och innehöll inte så mycket av värde. Tråkigt för att vara en keynote. Det jag kommer ihåg var att han pratade om framtidens enterprise-Java i anslutning till vad Spring-ramverket kan hjälpa till med.
En djupdykning om hur JVM:en fungerar idag, hur den kanske borde ändras om för att bli bättre och vad som borde läggas till för att bli effektivare. Han gick igenom några “magiska” saker som JVM:en ger oss som vi ofta inte tänker på att vi har; illusionen om oändligt med minne, att bytecode-exekvering är snabbt, en konsistent minnesmodell (oavsett underliggande hårdvara), konsistent trådningsmodell (samma sak här) och att lås är snabba. Rätt djupa saker, men intressanta. Sedan kom han in på saker som vi tror att JVM:en har men som inte stämmer. En ögonbrynshöjare var att trådprioritering nästan aldrig fungerar på Linux. För att du skall kunna ändra prioritet på Java-trådar under Linux måste ditt program köras som root och hur ofta händer det?
Presentation om hur du får in Java 7 i din produktionsmiljö. Java 7 släpptes ju i slutet på juli och har haft lite tid att mogna, men än har inte många valt att gå över till Java 7 i sina produktionsmiljöer. En sak jag inte visste var att Java 6 har sin EOL (End Of Life) i november i år, vilket faktiskt pekar på att vi borde gå över till Java 7 så fort vi bara kan. Enligt en undersökning som Markus visade siffror från i sin presentation har endast ~17% gått över till Java 7 och ungefär hälften har inte ens en plan på att överhuvudtaget uppgradera. Detta är lite skrämmande.
Han gick också igenom några steg som man bör tänka på när man skall uppgradera. Sammanfattningsvis innebar de att testa att din kod + tredjepartsberoenden fungerar med Java 7, kolla om din kod använder deprikerade saker, kör dina tester om och om igen (för Java 7 kan exekvera dina tester i annan ordning än förut, vilket kan krascha tester om testmetoderna är beroende på exekveringsordning (som du faktiskt borde fixa ändå!)) samt kontrollera vilka nya features som finns i Java 7 som du kanske borde passa på att använda i befintlig kod. Koden uppgraderar inte sig själv till Java 7, så lite försiktig bör man vara.
Sammanfattningsvis en introduktion till DDD tillsammans med CQRS med faktiska exempel. Fruktansvärt intressant! Jag skall inte gå igenom här vad DDD och CQRS är, men om du vill lära dig mer så kan jag rekommendera www.dddcqrs.com. Presentationen öppnade verkligen ögonen för mig när det gäller event-drivna system. Kärnan i det hela är att du inte persisterar state på dina domänobjekt, utan händelser. Ett state för säg en order bestäms alltså av ett antal händelser som skett i systemet; exempelvis “skapa order”, “lägg till orderrad”, “lägg till en till orderrad” och “lägg till orderadressat”. Om man modellerar sitt system på detta sätt kan man göra så mycket häftiga saker. CQRS är så mycket mer än bara den event-drivna biten, så jag rekommenderar dig att följa länken ovan och lära dig via exempel och videos som finns på sidan.
Kort fikasession om Hadoop, vad det är och lite hur det fungerar. Hadoop är ett distribuerat open source-ramverk från Apache som kan hjälpa dig persistera och hantera stora mängder data. Ramverket är inspirerat av Googles tankar om MapReduce och deras egna filsystem GFS och används nu av flera stora aktörer som Facebook och Twitter. Det är kanske inte så många företag i Sverige som behöver titta på detta än, men det är en väldigt häftig och smart modell för att hantera stora mängder data.
Synd att presentationen bara var över en kaffepaus (den varade i ca 15 minuter) då ämnet intresserar mig. Hade varit trevligt med en djupare genomgång med exempel på hur det fungerar mer i detalj. Får väl hem och labba lite antar jag =)
En introduktion till Clojure som är en Lisp-implementation i Java. Neal gjorde (som vanligt) ett bra jobb. Clojure är alltså ett funktionellt språk som är extremt flexibelt och väldigt lämpat för “concurrent programming”. Jag själv har inte mycket erfarenhet av funktionella språk, så det var kul att få en genomgång. För en Java-nörd som mig känns det som en rätt stor tröskel att komma över innan man kan skriva kod i Clojure utan att snubbla över syntaxproblem. Jag skulle nog inte rekommendera Clojure som första funktionella språk för någon som “bara” kodat imperativa språk som Java innan. Men om man kan det och använder det på rätt sätt så kan det nog vara ett sjukt effektivt programmeringsspråk.
Fyra punkter som sammanfattar Clojure:
Väldigt intressant (och kanske lite kontroversiell?) presentation om hur man bygger REST-API:er på ett bra sätt. Rickard gick igenom vad REST är och hur Roy Fielding (som myntade uttrycket) tänkt när han skrev specen. Sedan förklarade han hur han varit med och byggt ett system på REST med en väldigt tunn klient. I projektet han jobbat i kom det fram till ett tankesätt som passade dem bra; “exponera use-case, inte domänmodell”. Vanligtvis brukar man exponera sina domänobjekt via sitt REST-API, så att en klient själv kan bestämma vad den skall göra med datat. Klienten kommer i detta fall hålla affärslogiken och ta beslut om vad användaren kan göra i systemet.
Rickards tips var alltså att dra gränsen mellan server och klient närmare klienten, så att klienten blir så tunn som möjligt. Affärslogiken för systemet hamnar då på serversidan och klienten får endast reda på vad den kan göra genom hyperlänkar som returneras från servern. REST-API:t innehåller endast representationer av de operationer du kan göra på ditt data, inte datat självt. Det är denna bit som kan anses lite kontroversiell, då man helt tappar CRUD-access till domänobjekten själva via API:t. Om man gör på detta sätt så hävdar Rickard att man får en hel del fördelar med att underhålla sitt API och sin applikation i helhet. Man kan då enklare uppdatera systemet genom att all affärslogik ligger på ett ställe; i servern. Klienten är bara “dum” och följer bara de länkar som REST-anropen returnerar. Intressant tankesätt som tåls att tänkas på..
Dagen avslutades med mingel och god mat i Stockholm Waterfronts lokaler tillsammans med massor med intressanta människor. Jag hann också med att gå på en icke-formell Open JDK-session som Fredrik Wendt har skrivit om här.
Jag har stött på tillfällen då man undrar vilken implementation av en kollektion, t ex java.util.List man bör välja. Ibland behöver man använda så lite minne som möjligt, ibland vara så snabb som möjligt, osv. Jag har oftast löst det med att skriva enhetstest och långkörarjobb som gör något om och om igen, så får det stå över natten och när man kommer tillbaka nästa dag undersöka resultat, loggar och JVM-data.
Skärmbild över statistik från körning med Caliper
Idag hittade jag Caliper via Jesse Wilssons bloginlägg om LinkedList vs ArrayList (ur kö-perspektiv). Den korta tråden av kommentarer visar dock på hur irrelevant enhetstestbaserade undersökningar kan vara (även om de kör över tid så att GC får arbeta). På en JVM sitter ofta många system och “delar” GC och minnesrymd.
Helt irrelevant finner jag det absolut inte – även om systemet under test inte beter sig som under skarp last så upplever jag att man kan få ökad förståelse om hur olika implementationer beter sig och ju mer delar man har av ett pussel – ju lättare är det att se hela bilden och dra rätt slutsatser.