Think Async in Java 8 by Dmitry Aleksandrov

okay I guess we should start because we are three minutes ahead of the schedule so I would say chased since thank you so much for being in my session so I have actually two big challenges the first challenge is that you are off to lunch so you may be more sleepy the second challenge is that I'm reading this session after the session of dr. Frankel Subramanya so it's even more challenging for me right now as few words about me my name is Mitra Alexandre if I work for tea systems and I am Bulgarian Java user khalid and as you see from here i like airplanes yes i even go to program this one a320 but i'm mostly you know involved in coding in java and mostly for blood enterprise and i also try to do conferences so okay so are we a plan for today we want to rethink the way which we use system resources and i truly hope that after this session you will at least try to you know at some situation you will trigger the event how would you do this or this or another stuff so and to do this we actually need to understand one word which is the word asynchronous so what do you like it from wikipedia what is i synchronous so I think for this is a form of a computer control timing protocol which a specific operation begins after receiving a signal and the actually the operations are going not the same rekt or not exactly the same rate together with something else and in simple words what we actually do so I start talk somewhere else we will not define this else but somewhere else somewhere in the background and after this task is ready actually we want to be notified that we have the result and I need then after we somehow take this result and process it in terms of Java or the other languages so we what we usually do we start a new thread put some work inside there do something there and then try to think how should we get out this result from there and so how to process it so the the there's a big carrot on how to get this result how to get it synchronously and so on and so on and why on earth should we actually do I think with this stuff yes because it can be really faster yes it can be faster because why because there is it's a non-blocking approach because there are no gaps between tasks while after the task is ready we start with another task and as its non-blocking we are actually benefitting for them because blocking is waiting it's doing nothing and as we do nothing all other resources are just wasted and we want to avoid it at maximum possibility as it is so I'm to get this understanding on how can we do this in a Java 8 nightly we need to have a look it's from some different perspectives actually because several technologies made it possible you know we actually involve to this position so now we can use it quite easily so let us make some you know step back to history and see the evolution of multi-threading so all of us mainly in universities I guess somebody are familiar from schools we have begun to offload some work as we start new threads so it was kind of a very you know straightforward we implement runnable so do some work in the define some work to be done in run method then we just talk to you thread or we even can extend the thread and do some work there but at certain point we realized that you know parallel programming is very hard is not just a floating a work somewhere there and taking it back and it's very hard so all this waiting healed ink you know synchronizing and so on and so on it's very hard how many of you have read this book how many of you have read it once and understood everything okay how many of you have read it 10 times and understood at least 10 percent that's me I read a view every year and every year I find something new yes because it's very very hard but still this book is amazing and it says it's a must read book for everybody so and at thirty point in 2004 people somehow realized that this concurrency stuff is very hard and we have to make it a little bit you know easier and that in 2004 there was released this concrete API with a java size and there were several constructions which are which were available to to to people to to to the users which somehow put off this low level abstractions to do something client level and at least they thought it will be more understandable it's still not very much understandable but still valid they have introduced this thread pools or we could now offload this work and somehow they execute this work do this asynchronous stuff and so on and so on still it was you know kind of a little bit you know of high level of abstraction and with it came the future yes so what is the future actually by the terms of you know of theory this is a primitive for creating a movie Asians and you will be surprised this is something not very much new the first concept of future was introduced in 1977 I wasn't even planned to be born at this time by this wonderful paper of Henry Becca Kong Hewitt actually was about garbage collection it was fun and what is actually a future so if you know every function so ever every work in our no computer computers are made to calculate something to do some work for us and a function is something it produces a result so and as this function produces a result we have a function we want to put this work or actually the production of this result in some kind of a container because containers are now everywhere we cannot start a conference if there is nothing worried about containers but container is not a you know theoretical theoretical defined word we use it just for our abstractions so we put this work the result of production of this work inside of a container when we actually handle it and care for it so and you know putting this work in a container you will be surprised there is another word which comes always comes together in our you know in an immersive future he's actually the promise so promise in actually calculating of this work asynchronously and putting it inside a container so container we can consider it as a you know write-once container oh well promise puts a work so this right once container is cold future so we always come together we are sometimes believe that future is a promise and promises the future actually not they are different parts of the sale so on you will be surprised that this is actually not very much new stuff to you because the term promise was proposed even earlier 1976 by then L Friedman then with wise and Peter Albert called it eventual just you know try to understand try to feel the word eventual so we have this core word of event here so this is a wonderful paper I could even buy it on eBay or something like this it's not public but it's very interesting to read so and and we talk about you know work inside of a container and so on the main concept of future is that all the magic all the work should happen inside of this container without ever leaving it so we put a work we open a function there it produces some kind of result we can transform this result in a container we can chain this transformation of the result but and then at the end as we actually produce whatever we want we are eligible to take this value out of it we cannot just you know take the value put inside a container do something asynchronous then pull it out do something can synchronize and put it back so we actually by the concept we should never actually remove the value outside of the container and as the expected you know calculation expected result is done we actually do callbacks to pull it off and use it so it's a final terminal operation in our in work with the futures and promises and what was this future in Java actually it was a nice structure quite nice you probably all know this code so we take a an executor service we submit some work inside and we try to ask is it done is it done quick is it done it's done and as we are actually bored to be checking is it don't we just get the result and that's it so the API is quite simplistic but there is one one small drawback in all this thing so we're quite close to theory but we are not because gap and guess I'm out up blocking operations here by this functions get we are actually breaking the law so if we take a look at this diagram so there is a main trader at a different fret to resubmit to work there we submit the work and as we submitted so we can continue our work as it is with with zero done time we'll just continue our work in our trade and this work is offloaded to be asynchronous but of course we usually do get operation as we click an operation the main thread blocks and we are waiting for trend want to finish it work so all this time which you when the results already we are actually blocked with doing nothing and what we want we want to know somehow put the cat and do something useful in here in this in this main thread so from the definitions we don't have to wait a block so how do we escape from this situation so of course we do callbacks yes we say ok I offload you the work and then when you're ready notify me somehow ok let's imagine we have a kind of a construction which is done with the with the Java 8 stuff with suppliers and consumers and this is actually doing one thing so it takes an executor service get the result from the supplier Rob sits inside of a try-catch block and the on successes accepts it or on sale it just you know here I said except but we can write a lot message or something like this so and let us try to do something useful so we want to calculate we Balaji's numbers which can be a time-consuming operation for my demos I try not to use the internet because it's usually fail so Fibonacci is quite you know or even prime numbers we can use prime numbers here for the next time I'll write prime numbers the time-consuming operation so it can be offloaded and what we say so we can synchronistically Bonacci put inside this executor and print line and if something goes wrong we just you know print stock trace okay that looks pretty nice you know with this small rata we quite gracefully offload this work to another threat without even noticing it but what if we want to change something or example we want to calculate prime numbers like here we want to calculate for you notches numbers and we want to make an intersection between this I don't know it's a quite a weird idea but for some mathematicians this may sound reasonable I couldn't find reason personally but it's a good example because it does not use internet and as you see this code is not readable it's not maintainable it's not even debuggable I would say because only actual work happens here in this red lines and it's it's ugly I would say nobody writes like this although we have all this opportunity to do this and actually the same is the story is if they try to do this somewhere else all this approach and of course everybody remembers this know just how many of you have coded no GIS in production I mean in a real hardcore production lucky you because you know they have introduced this non-blocking API with event-driven Moodle and of course while the new for that time was that everything was made asynchronous based on callbacks and that was so much cool all this callback was ok this will you know solve our problems we don't need JavaScript itself is not a multi-threaded language but it was still able to do this Ally synchronous stuff very beautifully but in reality we came to this wonderful picture callbacks everywhere yes which led to some other picture which is called callback hell yes in production it was undi bhagavad to work with this and here I'm honored to cite 8dr bankruptcy Ravenel so if you say callback to a JavaScript developer he was tied crying instantaneously yes this was the message from from his last session he has so in reality it was not so much cool and people start to think okay we need some other mechanism to fix this and this then came this promises library cue library so it was really a wonderful approach so instead of doing this you know inlining I would say function in function calling function calling Kobuk calling back other function the queue library actually allowed us to make a call and then with the construction of the word then we could change different events which are happening actually asynchronous but we can chain them and gracefully handle exceptions and gracefully handle the final result so all them things you're actually happening inside of a kind of a virtual container which you know all the works happens inside of this this construction of q and after we are done we're just you know getting the value out of the container or do something else so but not only in JavaScript so as you see the future in Java five starting on Java 5 was actually a kind of a not full future it was kind of partial future which violated below and the guys from Google say ok we don't like it we want to make it we want to make it the real future and it should be by by by theory so they have created this honorable future at this time but it was you know complicated it was really complicated usages in the production nobody I saw maybe because of the light nobody okay you're kind of a lucky somebody of you have worked with Cassandra databases well actually there are compose futures from guava they say okay we have this contract of this operation which can be time-consuming as its time consuming we return you the future of this operation but not just the future reasonable futures so you can do more thing with it and to use it it was hard so we have to decorate our executor we have to we could add callbacks in quite in a civilized way but as I said I try to use it once in one project and it was complicated but it addressed a very very good idea of the fact that we do not transform the value out of side of this container so actually everything happens inside of this virtual container which handles always work inside of a you know controlled environment of future and we can transform the values inside so guava gave us the opportunity to be more theoretically correct in using a future and promises then came another a library it's called the J deferred library I think that right Zonk is yellow one of the office that he is now on this conference so you can be you may talk to him and there is a very nice article by always on me right here just happen now on this latest Java magazine and it actually helped us a lot to transfer to work the same way as we did with the Q library and Jennifer if you miss this article especially is very good in the idea that we actually separated the futures from promises which is not going to be able to do in the pure Java so you may try but there is one small drawback here is that sometimes we are not allowed to use third-party libraries there's a quite a production situation especially in banking environment so for every library you have to get a permission and the if we're not allowed we have to do something else and so the idea is how to achieve a nice synchronicity in Java 8 and you'll be surprised maybe not surprised because it's not a new material so actually Java 8 is available since 2014 how many of you really actually use Java 8 in production my god how many of you are used not only Java 8 JVM but the features of Java 8 like streams Oh fewer less hands so still still naming name in in many many years you know companies the migration of Java 8 happens to come just to migrate the same code to another JVM a so but this was a game changer which was in my opinion comparable to lambdas and streams but it was some kind of a little bit forgotten so in Java I ate a synchronicity is done only by one single class it's called the completable future and it's available since actually 2014 March 2014 which is a it's in the core library since Java 8 so how would they eat it so they have used the future emphasized and they have added another interface which is called completion stage and computable situation inherits from extensity of this interface as you know in Java we can extend to multiple interfaces normal classes and they vary a lot of magic inside of this on this completion stage so from now on we are able to do composition of elements functional resolutions transform the values inside chain the values inside completed the futures and do always think synchronously and both asynchronously and to you know to get to this class we need to talk about self foundations so the foundation the mainland first foundation which makes us easy to use this classes are of course in a lambda send method references so Java 8 actually had them and the computable future of course benefits from them so as you saw in the guava example it was very very hard to write something reasonable for callbacks because you have a little to write a lot of codes which is quite a fun maintainable it's really unmaintainable and unlivable so here you just use lambda center method references the second big foundation came actually from Java 7 as the fork/join thread pool came available and it become a an amazing helper for asynchronous operations because why so by the algorithm itself is care much for cache corruption so what do you mean cache corruption as you see it's very good if one task operates on one single core so and we know as we use the data the cache lines are filled with the data which is mostly used and the cash heats are actually speed ups in our in this and this approach but we don't have this unlimited resource of course and that's why we have to split our tasks to multiple cores and for joint here with its no work sealing algorithm and it's in its theory helped us a lot to keep as much tasks in one processor the more time possible and just right one the you know the queue operation is full and we have you know all the thread fill up with tough then it just steals back from the task from the queue layer from the task queue the last stuff keeping the task like here which are closer to be executed in the same thread by that's why you know caring about this cache corruption so we are more likely to have cache lines cache data cached inside our processor which will be mostly used so 50 foundations so in terms of in terms of you know how we use it actually made it very very easy to introduce completable future to to our developers so if we go back to completable future so how can we create such a future as we say just a class since just a class we can use a new approach so we create we can created an empty container I would take like this for some job to be done just like create a new class but there are much better ways to do this which are actually supply think and run I think so as static member studying methods and we just as you see from from the definition we sipped see the container okay so this is the work that has to be rubbed inside a container and given to you this supply sink or with run a sink which is this is the work that has to be done and please as you run it we don't care about the results of just what I think by the way let us try to do this I have prepared some some small code for you I think that screen is so much big that you're able to see everything yes I have no no no reason to enlarge it I'll do something like this it's okay okay so as we say okay we want to calculate prime numbers prime numbers is a time-consuming operation and we don't want to do this in a thing for this way so we say put them off huge okay okay just give me a second I will even do it like this okay so get prime cesarean the code here so if you make a compatible future of it completable future and as we say we just supply some operation here and we pass a method reference which is an OID is very great support to here and we say after it's done okay please print it okay system dot out dot not dots double dot we need a method reference print file si so we supply think we say okay I'll float this somewhere else calculated after we done please so show us the result or what will happen okay it's working good working collection nothing happens what's wrong here why don't we have any result somebody has an idea exactly so we have now just done our multi-threaded program without realizing this is multi-threaded program so and if you say for example system.out.print line and here we say I don't know if I'm writing is correct but chase this direction or the other direction okay croco you see as it's a synchronous approach we just wanted we only receive here this hello croco because the other thing is uploaded to different threat and the to realize actually we have to do some work with the rule the work really happens is that we can do for example system dot in dot read something just to prove that it's working and you say it now works somewhere there works okay you see after some times the tread actually as it's done it has calculated we change our events so that we just print them out so our program is working but we have just now done a multi-threaded programming without even realizing for doing when you move the threaded asynchronous programming looks pretty impressive huh so this is our approach by the way as you see the power of computable future is so big that we actually can supply our own executors here but for default we use for a giant pool so as you say for determination we can actually complete this future or complete it exceptionally that means that we're saying okay here we have a failure we declare this as we have completed exceptionally but it can be completed only once and as you probably saw there are different ways to complete them as well we by chaining the method so we start a new container put some work inside on it do some work and we have a terminal operations like then except that we consume the result or run something after a result is consumed and by the way remember this so that the transformation has to be done inside of a container this is nicely done by then apply function for example so as you probably saw we can now calculate this and then we can change somewhere else here like for example I think I have prepared in this show get average so we receive a list of operations and we want to get an average of all this you know prime numbers and you see we do all this transformation right inside of the container the container does not the value the calculation self does not leave the container so that's so that's kind of a very interesting results for mathematicians as well like you know nine thousand I don't know why it's like this but you see it's done completely asynchronously and it you know compliance the comprise the approach this theory underneath and as you see it starts very very beautiful and if we dive deeper we have a very big infrastructure here so as you see we can do smart transformations because as it is a class we can return a completable future or a completable future of a completable future that is absolutely possible is legal but we don't want to do this and that's why we have this thing cantos method and then compose async matter which help us to avoid this situation of completable future in completable future it works it's like a flat map so it just unwraps it for us it's very smart we don't have to think about it so if for example we have a synchronous operation of reading a file and then we have an event like for example read the file then process the file and then print the result we are absolutely okay to use the compose method it will unwrap for us all this computable features inside and we are completely beautiful you know asynchronously chained here or for example we want to combine some values for example some futures - we need a result of two futures and we can use then combine method and then can buy to think method so if we use for example to calculate prime numbers and people notice numbers in terms of usual futures we have to put this work in futures and then make to get operations which is bad because get some blocking and with the construction of then combined we don't need this I will show you later in the demo and of course if we don't want to further processing we need we can call of course method like except both or run after both so two futures as they are done and accept both or except some of them accept either that's an interesting situation for example you need we just want a first available result and a good example here is a DNS for example we have several DNS service and we say ok all of you who knows this address and the first return the dress is actually something that we need so it's a we don't need other results from the other service but what happens to the second results actually the second result in the idea is that this future action never completes and it may be hanging around because there are by the instructions of not contraption but the approach of future several other futures can be you know dependent on your future so by this operation like accept either or enough to either you just handle with care you can also get the number of dependents to see so of course we can apply to either operation so as they're done we can apply some transformation or we can have a more generic methods I call all of the future so we can wait for all of the futures to to finish or any of the futures to finish just like in this DNS approach and the DNS example but we have a look at their results so all of is void because here we cannot predict what actually ah they the what are the other futures beta we can supply futures of string integer or a lot of class here we cannot predict what will be the first available or all of the first see it's not possible for any we have an escape of object as you see so it should be an object but then it will be kind of a uncertain one of the collapse so here we lose the type information that's why I personally never use this methods inside of my production and as we were talking so a very exception on the previous session of the doctor bankotsu Britannia is the exceptions and this approaches are handled like normal operation that's not a stop of the world and the only approach of this synchronous completable futures are the idea that exception can happen and we are able to gracefully handle this exception and make it part of all of our process so first of all as you see we can exceptionally hand finish our future or we can handle it with the with a handle function which actually accepts by function which is kind of a beautiful because here you have this lambda with two values first one is the value which is producing the next one is exception so if everything is okay we just continue or if we have an exception we just do something else so we can you know put it inside of the chain and gracefully handle because the exception is propagated through all of the chain and here this is a normal result so if we go back to all this to this function about reading files you see the code itself becomes very very beautiful so we supply two synchronously we receive a future we compose it without our future as it is we print the results and if something goes wrong we can handle it gracefully and as you probably noticed and so the unlike the future the API of the class is really big yes although it most mostly fits us or we have methods that have synchronous asynchronous err in O versions of it what it most fits to this pattern but there are more almost sixty methods inside it that's why this class is called one of the scariest in Java 8 there are many friends of Maya say why don't you use completable futures we say because we don't understand all these method names yes we can we just it's very hard to use but still if you get used to them it will come very naturally for you and I personally believe that this is one of the game changers in Java itself in decades so computable features are very nice if you start to think about this chains or flows of events and you events and talks themselves so not every not every problem is okay but if you are able to think inflows events and tasks futures completable future construction itself is is something for you but though here we have some bad heredity and of course is the get method get method is blocking so because we actually inherit from computable future and we have to live with it but this get method is actually both good and bad because with cap method you are able to do synchronous calculations so for example if you are designing an API and you know you use declare by the thing that this result is rotten computable pleasure you somehow declare to your customer but okay this operation may take that it's it's a long lasting operation and the client itself can design okay it is a lot of the long lasting operation I can change some event or if I want to make a synchronous I just make get the function get the result and as you see because there are streams eighth grade also a joint operation this joint operation is very interesting is also get operation but this get operation is is does not throw a checked exception and it's very beautiful I made small demo for you how can we use this as we see we are able to do some asynchronous jobs some parallel synchronous jobs let's imagine the following situation we have two sensor we mails this emails can be say absolutely asynchronously getting parallel so the dis operations are not dependent from each other so and how can we how do we usually do this so we do this with parallel streams because because they're just you know very easy to use but let us I will say you I'll show you the task itself the task itself is currently very very you know easy so we just sleep for one minute but maybe here we're sending an email since we don't have internet we will imagine this we do Carol the task but we want to make it a little bit different we say okay so sending a task with a rocket in a computable future and just throw away somewhere asynchronously and then we receive back the results why do we want to do this it gives in parallel streams we are not able by means of the construction of the construction of parallel streams to say which executor should be used and in parallel streams we only have this work joint pool available to us here in completable futures you saw the construction we can submit other executors and we want to benefit from this and if you will notice which is interesting here if we run the same stuff here just give me some more is some more time as we construct here by parallel streams you will see that we have a foreign joint pool common worker so we were using full joint but all the sending of an emails will take each of the talk plus one second but it takes about two seconds to send all the messages if we do the same thing here with computable future and submitting it to other executors which now I think is a just so you know not a foreign joint executor but so just usual fixed-rate executors we will do the same task only in one second you see this availability of executors to be submitted to computable Fisher makes this very good job because the component of future itself can now benefit from other thread pools and we are okay too we have really one second benefit here which is which is observable so when this joint operation is kind of a get which is non-blocking cooperation we are it's done mainly for for working with dreams because we in streams we don't have possible its workers check exception so you can also approve a lis which is you know to see what's happening inside but never do this so but heaven wines so a good example for this which we actually is in our project is that we as an enterprise we want to calculate something in a synchronous way and send it back to the client and unfortunately before Java EE 7 we had to use these scan operations because we didn't have any construction for this we have to do asynchronous stuff to certain point after Java EE it looked like this so all of our main thread actually was blocked every time well two threats were calculating the values but in a seven we had the possibility to do an asynchronous response we had an interest infrastructure to do everything asynchronously so we calculate all our stuff here we apply the results and we apply the result directly to this asynchronous response so we received an opportunity to make a real chain of asynchronous event even on the server so that's a good example this so as you see the primes as the values are calculated we are not blocked in this part and not only on the server itself in Java surest we have received a possibility even on the server to get this because with the new Eric function we receive as a result a completion stage not of not a just the future so we are able to do this truly asynchronous on both an server and client but still belief get his evil I mean if you are designing your API but try not to use gap if you are trying to make it asynchronous and as you know July 8 rice in July 17 or not exactly July 17 or we don't know yes there is a JEP which actually extends to work and it gives you a possibility to make some better work with computable futures so it's a it's not only tied to Java 8 and as you see there is in some strange work if you supply synchronously you know work we can complete it with a default value and make our get method not blocking and we say ok while this value is calculated pre submitters return always return another value which is a default value for example well it will if we call get so but this makes the program a little bit unpredictable so we can complete the future and the good part here is that we have more possibilities to work with the timers and schedules by the way the first talk about computable future so was done by your citizen Tomas lukovitch I think amazing guy and there he introduced this unblocking timers schedulers with some tricks a very nice idea but here you can do this even more beautiful so we have time outs build inside of the of the of the completable futures so and you can complete it both with by function so if the price is calculated like in this example please do something if not sorry we cannot return so we are tied to two climbers here oh we have this complete on time out we can either have a default value or in in one second for example in one amount of time or we can if it's not calculated in this in this period of defined time then return something default it's an option but I feel there is my personal approach is that there are several uncertainties about about undefined behavior so this undefined behavior is dependent now on time and it's very hard to see this the the program is actually returning responding correctly but at the end I wanna say a few words about reacted yes mister dr. Venkat suburban young give a very good explanation about reacted but still I will have my small approach so what is reactive as you say it was the new cloud so if you program reactively you have all these benefits yes which are written here yes but until the server listen I became so now if you use server less you receive more benefits but still it's not something new as you say it's reabsorbable pattern so the key word is asynchronous and actually in this completable future is quite near to this pattern here we say if you read this wonderful manifest don't know everything has manifestos and reactive has its own manifesto of course and of course we take a look at this wonderful picture which is shown on every conference worldwide we still see that a little of future is quite nicely fitting in this idea of responsive elastic as we say we work with the resources for use multi-threading underneath without even realizing we have the Moody threading and it's very silent so we keep them the exceptions as a part of the flow and it's either handled gracefully now in this case the only thing is hidden from us this message driven ideas so this message retriever idea that okay I'm here I have finished my task I now signal you to continue by the chain to do the same stuff it's hidden from us so we don't have this message driven available but still if you see a directive is good for a for CPU usage for caches and so on and so on and even if I I've created as an example API and see that we by using only computable futures by these gaps that we don't have to kill without this blocking we think that could serve more response today so the blue graphs is actually the result but it's only by introducing this non blocking approach so it looks really nice quite nicely fits to reactive patterns and what's great about computable future is that comes out of the box you know you don't have to think to use different libraries and to you know care for them much because if it comes with the JDK then it is tested what is beautiful about something that comes from the JDK it is tested it works good it works proven so Java 8 is one of this thing but handle is care and I say once again mind the gap so and synchronous application you may have it an asynchronous you can you know do it without it and then it's all from my side so changing clear Bardo you [Applause]

Channel: Devoxx

Views: 17,651

Rating: 4.8658538 out of 5

Keywords: DVPL17

Id: 1QW2m0q_bN4

Length: 52min 19sec (3139 seconds)

Published: Wed Aug 02 2017