JPoint 2017 is a conference that could. Review of the best reports in the public domain

Recently, a colleague asked the usual questions about "why go to conferences" and "why watch the recording on YouTube." Since this is a friend, and not just some arbitrary person, I wanted to answer in more detail, in detail, and in garlic. Unfortunately, online, with live communication, it is difficult to do: just do not remember all the details. On the other hand, this is a great topic for habrapos: you can write a detailed review once and then, like a true social phobia, answer all questions with references to Habr.

The idea is simple: you need to take the most popular reports from JPoint 2017, briefly retell what it is about, why it’s cool and why I need it. Each of these reports deserves a separate analysis, but first a brief overview of the top ten. Go!

Interestingly, it was at this conference that two keyout hit the top. Keynouts, by definition, set the spirit and tone of the conference, they are designed for "inspiration" and "broadening horizons." In order for a keyout at a narrow technology conference to hit the top, you need to try. However, they are all here. The program committee has achieved this with a simple trick: the first keyout is a traditionally popular teacher, the second is done by Shipilev (a repeat speaker, a serial maker of the best reports).

To compare your feelings about viewing the report, next to each of them will be the average rating of the conference participants.

10. The task of collective (without) responsibility

Speaker: Alexey Savvateev; rating: 4.38 ± 0.04.

A vivid report from the popularizer of science, in particular - mathematics and game theory. The report is based on our own research and on the work of Oliver Hart and Bengt Holmström (Nobel Prize winners in economics in 2016, who were given for the theory of contracts).

First, a certain introductory is given for those who have forgotten (or never knew) basic things about game theory and contracts. This distinguishes the keynote report from the “hardcore”: the author did not say “everyone who filled up the materiel in the university got up and left the hall”. Instead, he briefly and clearly explains the topic with examples, so that it becomes clear to anyone. For example, the theory of contracts can be used as follows: if we have some ordinary coders office, then a model of all involved persons is built (employees, employer, etc.) and then the employer can control this system not by direct orders, and with the help of finely chosen incentives.

Alexey cites a large number of examples of such contracts, including those that work poorly. For example, it tells how using incorrectly selected rules you can accidentally block car traffic. In short, the overall task is how to organize the process correctly.

In a series of examples, we come to an explanation of the Nash equilibrium using the example of the turnstiles problem. Nash is the comrade who was the main character in the film “Mind Games”, received the Nobel Prize in Economics in 1994 and the Abelian Mathematics Prize in 2015. Nash proved a very general theorem of the existence of equilibrium in games. There are such actual examples as money and faith in their value and comparative confidence in the quality of teaching in universities.

It's very cool that Alexey right in the course of the report organized the brainstorm together with the audience - and there were really people in the audience who could keep up the conversation. Usually such attempts look pitiful, but in this case they were part of the report. Unfortunately, it is impossible to feel this on the recording, but it was one of the few reports where I was present live. For example, the second part of the turnstiles problem was discussed in this format.

And finally, based on this, we turn to the central topic of the report: how the speaker was asked to solve the problem of not paying taxes with a high level of corruption. A model is built, the problem is formalized, and the problem is solved within the framework of game theory, during which we stumble upon a number of very interesting consequences and observations.

Generally speaking, this was supposed to be a critical article, but it is clear that my knowledge of game theory is never enough to criticize a real scientist on his battlefield. Did he choose the right model? Are the calculations correct? Yes, God knows. First of all, I was hooked by the author’s way of thinking, which can be traced both in the videotape of the report, and when communicating live. This way of thinking is like handwriting.

All programmers somehow solve the problem of modeling in their programming languages, but in the case of Alexey, the talk is about extremely complex real-world problems that pull on very high-level mathematical abstractions, which together allow us to construct very counterintuitive conclusions and test them in practice. For me, the keynote value of this report is precisely this - in the instant of sudden enlightenment and insight, when you begin to see the “Matrix” of simple things with different eyes.

9. Performance: What is in My Name to You?

Speaker: Alexey Shipilyov (Red Hat); rating: 4.38 ± 0.03.

Another keynoat, this time about the performance. First Lesha discusses the criteria for successful development. Of course, it wisely attaches itself to the audience, saying that the main criterion of business is money, and we, programmers, earn a ton of money!

While the audience has not recovered from flattery, bombardment with more sad technical things such as communicating with the security guards begins. From which it is concluded that performance in the top of the impact on the success of the project - not the most important thing. It's funny to hear it from the dude who is engaged in performance - usually every sandpiper praises his swamp.

Next, the correct program and the fast program are compared, and a slide is presented with the curve named Sh . IMHO, this slide is one of the most enlightening moments, allowing you to find yourself in the Total Picture of Everything. If you want to see only one slide from the report, then here it is.

Lesha is carefully traversed across all levels of the diagram, and for me personally these arguments have a very clear application. For example, this is a well-formalized list of arguments in the definition of a performance strategy and for dealing with harmful statements like “you need to profile either normally or not at all” (when you are in the green zone). Discusses the whip with its “premature optimization” as the main argument of all disputes. And how to sell your superiors work to improve performance. And what to do when people come to sell you some kind of game, such as a new super-fast database.

I'll spoil a couple of slides:

There are an unimaginable number of such slides, and that is characteristic - they are all strictly on business. Which, in general, was to be expected from the dude who makes a living by it. Not to say that this is some kind of super-secret knowledge, but for me their value is in the most precise, polished formulation and organization of information.

Examples, of course, there are tin: some pieces of code from javac with a drop in compilation speed from 2 to 8 minutes, evidence through Amdahl’s law and Universal Scalability Law , etc. Although where would Lesha other examples?

There is a suspicion that some experts on performance have now held a grudge against the speaker, for in one report he passed all their main secrets and topics of consultation.

8. Future Kotlin: Strategy and Tactics

Speaker: Andrey Breslav (JetBrains); rating: 4.41 ± 0.08.

Who has not heard anything about Kotlin? Well, definitely not us. All the news is full of Kotlin, the Internet is boiling up, and now the head of this project, Andrei Breslav, comes to our light. Andrei talks about the future of the language and platform, so he may well be mistaken, but this report does not make it less valuable.

Firstly, it is interesting that Andrei can really speak on behalf of the product. He can speak entirely with the markets at once: whether Kotlin will fight for Big Data from Scala, whether he will fight for Data Science with Python. If on the first slides he says: “Our creed: Pragmatic Language for Industry (Interop, Tooling, Safety) for JVM, JS and Native platforms” - then this is the way it is. In this slide, you can close the discussion in the chat about whether support for platforms other than JVM is a real priority.

Immediately Andrew explains that they are not trying to ensure that any program can be run on any platform. “Write once, run everywhere” is for Java, but Kotlin people will not do this. This is also a valuable piece of the mosaic - valuable for someone who is already designing Kotlin-oriented architectures right now. IMHO, for architects, this report is invaluable in that you can begin to understand from the shore who you contacted and what you are going to subscribe to.

You could also ask other uncomfortable questions like from the audience: when there is Objective-C support, useful libraries like sockets in Kotlin Native, etc. The questions are inconvenient, but Andrew somehow got out :-) There were a lot of questions about the native, the report seriously discussed the use of Kotlin in embedded. There was a question about Kotlin on Arduino and zero cost abstractions and a discussion that, if writing for Arduino as a server, is, in fact, a complete mess.

In general, the report was very specific. About plans, ambitions, strategy.

Obviously, it is very important for anyone who already connects their future with Kotlin. For all the others ... Well, let's say, there were some particularly “selling” pieces of the report - “eat me”, “drink me”, “buy me” - it was not there, and it really bribed me. Dudes have become so fat that they do not even need to sell and shake advertising booklets at every corner. On the other hand, if you initially wanted to understand why the hell Kotlin was for you, this is not a big deal, and you will have to be determined by some indirect signs.

For me, the main benefit of this report was not expressed explicitly, but a traceable idea: Kotlin of the future is not the Kotlin that is now. If something annoys me on trifles, then in the future it will most likely be corrected. In particular, people are seriously thinking about things like metaprogramming, which for me has become a blocker for Golang on a wide range of tasks. A very worthy idea that the plug-in to the compiler automatically becomes a plug-in in the IDE, which, when implemented with the Golang code generator, can again become a pain, and it must be solved. In short, Kotlin can be taken as a strategic decision with a great future.

7. Java bytecode verification: when, how, and can disable?

Speaker: Nikita Lipsky (Excelsior); rating: 4.42 ± 0.07.

The plot is such that Nikita did a simple student report on the anatomy of the JVM.

It turned out that not only students, but also adult mature developers often have gaps in basic knowledge and do not understand how the bytecode verifier works.

Things like GC are not required by the specification, and in principle garbage collection can be turned off (eg using Epsilon GC). In contrast, the bytecode is hard-coded in the JVMS and the same result must be returned to the same VM bytecode (regardless of whether it is correct or not). As a result, the verifier is written once, and then it is forgotten. (For the time being, we know that Value Types will require changes in the verifier.) And so there are dozens of people in the world who have ever written verifiers, and Nikita is one of them.

Here in this slide all the contents of the report:

And to the question “why go to conferences” and “why to look at the records” - it’s hard to get a coherent statement of these questions in the text form on the Internet.

Funny photo - the number of people who watched the class file from the inside. Almost the entire hall. Hmm, why should they? :-) Honestly, before I started digging into the guts of the JVM and just kodil web attachments, I didn’t even have thought of starting to learn such details, the same dullness (actually).

At the beginning, Nikita gives a detailed introduction on what the structure of the class file is, what bytecode is and what instructions there are, etc.

There is a game "who wants to be a millionaire," ~~like gil tene~~ and various interesting examples.

Next, together with Nikita, we go over the stages of loading a class into the JVM (loading, linking, initializing) from chapter five of the JVMS. Verification is the first stage of the linking stage. Then we go into verification details: static constraints and structural constraints. Static checks are done in two passes, the output is the control flow graph of the bytecode method, and structural constraints check more complex things, for example, that the stack depth in each instruction must be a certain value for any execution path.

The magic of the verifier works on static stream analysis, which is sometimes explained in institutes on the theory of programming or the theory of program diagrams. It was immediately clear that Nikita was somehow too succinctly presenting this part - and it turns out that he is lecturing on stream analysis. Somehow, a program about semilattices of properties leaked through the Program Committee of the conference at this place and so on.

All this materiel, however, easily falls on things familiar to the javist like Stack Map Frame and specific bytecodes. There are a lot of good illustrations about this. Moreover, we can even calculate the real time of the verification task, and what was done with it in Java 5. After that, a lot of different purely practical things are discussed.

For me personally, this report gave a strong rationale (both from the point of view of theory and practice) about why recommendations to disable the bytecode verifier ( java -jar -Xverify:none MyApp ) is pure madness, and that the critic of the verifier should be treated with a great deal of skepticism. In addition, it can be a great help when using libraries such as ASM (recommendations for using ASM are given right along the way).

6. Curse Spring Test

Speakers: Kirill Tolkachev (Alfa Laboratory) and Evgeny Borisov (Naya Technologies); rating: 4.45 ± 0.05.

This is a purely practical report, telling how to test pieces of their microservices and apply the various principles discussed in the report.

It is very different from previous reports on the JVM device by the abundance of things close to the web developer’s heart, such as a live chat demonstration written in Spring using standard REST and queue architecture. The burning questions on the topic that we can quickly lock and what will fall apart when using the naive approach are considered.

As an act of easy trolling, speakers do not test any arbitrary web services, but the brain of Baruch Sadogursky ( @jbaruch ) and Yegor Bugaenko ( @ yegor256 ). According to the condition of the problem, Baruch's answers are cached, and Egor may change his mind over time and always deliberates before the answer (receives data using a queue).

Writing about this report does not make much sense - it is necessary to watch it. Speakers vividly and interestingly show the basics of testing using Spring - not just some dry facts, namely, developing from scratch to a working application. It is interesting that initially many things are intentionally done incorrectly and then are evolutionally finished to the ideal.

I will accurately review this report the next time I’ll have to do a project on Spring and Spring Boot. It became clearer why you need @SpringBootTest (make a test for the full context, change properties, make tests with a certain crowd - package / configuration / autoscan), to maintain the test isolation - you need @TestConfiguration , and @SpringBootConfiguration needed only for @SpringBootTest signaling that it is time for him to stop. In general, it became clear that testing using Spring can be fast, but the cache is easy to break, and only @TestConfiguration should be used for tests.

IMHO, I repeat, in this report the development process itself and the understanding of its evolution are more important than the specific final list of conclusions. Independently, one can come to the same conclusions, of course - but with a worthless loss of a huge amount of time.

5. Spring - Deep and Not Very

Speaker: Yevgeny Borisov (Naya Technologies); rating: 4.46 ± 0.05.

Another report by Zhenya Borisov, which perfectly complements the “Curse Spring Test” already present in the top.

The conclusions of the report, suddenly, are given on the first slide, so let's go over them:

Spring is not perfect, but nothing is better. And he is still good enough, so we love him;
On Spring, you can and should build your platform;
Do not be afraid to repair it, but do not forget that he repairs himself;
Read the spec about the update.

Marrying starts a report with a famous slide:

This is the question of why you need to communicate live with the developers, go to conferences and watch the latest entries. Here is the observation of Eugene, I felt the hard way: much of the statements about Spring are either lies or hopelessly outdated.

For example, the idea of self-injection. When using transactionality, a bin that calls its own method should use not this , but the proxy itself. To do this, you need to inject yourself (or rather not yourself, but your own proxy). Where does this situation come from? Eugene explains in detail. This did not work until Spring 4.3, although you could use the @Resource annotation, and sometimes it worked, but in XML it always worked. Starting in Spring 4.3, @Autowired and @Inject started working, but not the standard Java config (Java semantics do not allow you to do such a tricky thing). And all this took four and a half years , starting with the creation of a bug in the Spring tracker.

The next example is about the damned PropertySourcesPlaceholderConfigurer . How much this thing (or rather, its custom implementation) drank krovushki from me. Zhenya points out that in version 4.2 it was necessary to specify it as static in the javaconfig (otherwise everything will fall with an error), and in the newer versions you can either specify only @PropertySource or not specify at all if it is Spring Boot. Between these things are also years.

Examples, by the way, burn with napalm. For example, circular dependencies between bins are illustrated by an example with a husband who injects a wife inside.

From these examples, I got the idea that shoving logic in @PostConstruct for blocking the launch of business logic is bad. To be honest, all these years, such an idea did not even occur to me (well, it’s because I’m a fast-coder), because all these problems are solved with carefully selected crutches. Zhenya tells how to write such a crutch correctly - the self-made abstract of @Main , which makes it clear that.

Roughly speaking, an eventListener is being made (a new component, in it above the method is the annotation @EventListener , and in the parameters, which event we want to catch). We need ContextRefreshedEvent . Then you need to run through BeanDefinitions, find and pull @Main . But at the same time, in order for all this to work under Spring Boot, you need to carry out certain manipulations. Here I will not describe all this, to whom it is interesting - look at the report. Moreover, for people who are not immersed in Spring, all this magic of methods with names longer than 80 characters seems like a game. However, the report tells how to make all this game automatically connected simply by adding dependencies to Maven, so that you do not have to go to this hell every time.

And further many more interesting, and sometimes completely forbidden things are BeanFactoryPostProcessor with writing BeanFactoryPostProcessor and BeanFactoryPostProcessor Spring versions. I am sure that there are people who have listened to Zhenya, used it all wrong and then burned them alive :-)

In general, the report allows you to better understand how Spring, Spring Boot work, and most importantly, ideology nuances that cannot be understood simply by reading Javadok. Here you need intervention and advice from an experienced Spring Jedi, which Zhenya is. This report (and other reports of Eugene) should be reviewed immediately, as the standard features will start to be missed, and you will want to write more BeanPostProcessor and BeanFactoryPostProcessor .

4. A story about how one HTTP / 2 Client engineer overclocked

Speaker: Sergey Kuksenko (Oracle); rating: 4.47 ± 0.06.

As everyone probably already knows, HTTP / 2 aka RFC 7540 is a protocol invented by gentlemen from Google or someone else to replace the old HTTP / 1.1 lamp.

The main role in the further narrative is played by several differences / 2 from /1.1:

Binary format (using Frames)
Multiplexing multiple requests in a single TCP connection
- <Request> => <Stream> => <Frame> ... <Frame>
Header Compression (HPACK aka RFC 7541 )

In essence, HTTP / 2 is such a low transport substrate that solves the specific problems of the previous standard.

On the other hand, OpenJDK has a JEP 110 , “HTTP Client”, which was released as part of JDK 9, but has not yet become part of Java SE. He was released just enough that you can see and discuss it. It looks something like you can expect: a constructor with URLs, a synchronous and asynchronous API, etc. The client is universal and works with both HTTP / 1.1 and / 2.

The speaker is the person who was involved in the performance work on this client, which he talks about in the future. The goal is to get a fast enough client for a reasonable developer time.

At first, he poked him in the hope that, perhaps, in the client, and especially nothing needs to be changed. The Jetty client was used as a competitor for comparison.

Somehow sad happened. In this case, there was a known problem with TCP_NODELAY , if someone remembers what it is. Sometimes people just forget about some especially famous shoals. Nevertheless, Sergey claims that all these things are not some secret knowledge, and typical shoals are very easy to googling and are studied by any newcomer.

I wonder how it works in the head of a real performance specialist. Not an amateur of some kind, but a real one. He did not read the specs of the protocol until the very last moment. I profiled, wrote performance tests, looked at the profiler interface - but I read the spec only at the very last moment, when it turned out that there are bold functions that release a lot of resources, but it’s not clear what they do. That is, the reflex “always read spec at the beginning,” is perhaps not the most correct one.

On the other hand, since you read the spec, read it carefully and use the hacks built into it. After using the right hacks, the client began to overtake Jetty - that's what makes life-giving specs!

In the report, all this is illustrated on real data from the subject area of the HTTP client. For example, the previous example for spec was illustrated by the procedure of expanding a window in HTTP / 2. Probably, for some part of the audience this question is relevant in itself, and all the examples with a rake there are really useful. To me, to be honest, it was not very: in the everyday practice of web bydlokoding you usually use such libraries once written once and for all by super professionals.

In addition, there is a set of fun life hacking. There is a myth that the performer sits around the clock in Mission Control and does some black magic based on it. In the practice of Sergei, most likely he will simply dump logs into a file and look at them improvisedly like this:

Immediately after this, it is clearly shown how in the network library one can refactor the bold code under the global lock into a quick queue. Locks are evil, and you can squeeze a lot out by simple refactoring.

At the same time, myths are being debunked that the transition from GC to pools will automatically make us well - in reality, however, we can come to a situation where we don’t have anything good from pools, but we have all the disadvantages of working without pools.

There is still a lot of interesting, but you can not turn the habrapos into a huge collection of screenshots (although you want to).

In general, the report leaves a feeling of a well-transmitted mindset of a performance engineer working with a network, which you may suddenly find yourself. And as a bonus, it allows you to walk through the typical rake of developing an HTTP client.

3. Fast and Safe Production Monitoring of JVM Applications with BPF Magic

Speaker: Sasha Goldshtein (Sela Group); rating: 4.49 ± 0.07.

So, we move to the top three. This report was particularly difficult to understand. The fact is that in order to write this article, I reviewed all the entries at double speed. Sasha in itself speaks faster than an ordinary person, plus the entire report is conducted in English. This combination really makes the brain, so if you listen to it for the first time - you should turn on the standard speed.

The bottom line is that the software that is usually used to monitor an application in C ++ or Python and on which Sasha ate the dog can also be used to monitor JVM applications. All this will, of course, be on Linux.

The global objective of the report is:

In this regard, the word BPF, which many do not even suspect, immediately catches the eye. In principle, on the Internet you can find other reports on similar topics, but not in relation to Java.

I will not spoil this whole wonderful report, but I will begin with a small seed story, which may cause holy awe in the uninitiated.

The report begins with a discussion of other monitoring tools, taking into account the status of their development (all tools are divided into new, stable and dead). For example, stable things like: ftrace , perf , SystemTap (it requires you to compile and dynamically load kernel modules — including on production). There are new things: SysDig (very simple, but few features), BPF with bindings in different languages. There are many other dtrace for Linux - dtrace for Linux , ktap , LTTng , etc.

Then we find out what things you can learn about the JVM. It turns out that in JVM there are special tracepoints that can be enabled and connected to them with external software:

In addition, Sasha wrote a tplist tplist that can be called as tplist -p `pidof java` and which displays all this in the form of a flat list, so that you do not need to read with your eyes.

Interestingly, all these points have parameters, so if we follow monitor__waited , we will find a structure of four fields (signed, unsigned, unsigned, signed). Unfortunately, in addition to the types of values, we just won't know anything about the parameters. But the info can still be found in .stp files, although not in the most convenient form. At a minimum, from there you can pull out the names of the arguments.

Further, to go to BPF , Sasha gives an example of an application that needs to be debugged on the prode: understand which piece of code prints heresy to the console, provided that the debugger does not allow us to connect. The task is terrible, the usual admin will run away from her in horror. You need to connect -XX:PreserveFramePointer (giving 3% overhead), and then use the trace utility from BCC :

 trace `SyS_write (arg1==1)` "%s", arg2' -U -p `pidof java`

trace always runs under root. Then we say that we need to treysit (in this case, SyS_write - syscol on the record), set the condition ( (arg1==1) ), message for output ( "%s", arg2 ), -U - userspace call stack, well , and of course to filter on PID. It turns out something like this:

Next, using previously written script scripts ( create-java-perf-map from perf-map-agent ), we turn the addresses of the methods into their real method names in Java.

Next you need to dig a little in the exhaust of our teams - and hurray! We just got a specific place that displays the right lines.

You can crank up such a trick on your prode: an ordinary inhabitant who is unaccustomed to such a tuling can consider this magic and believe in anything. Next time, you can tell the admin that you know how to read his thoughts and raise the dead.

This report is full of such fantastic things, which are actually explained by the use of advanced tools, including utilities from BCC .

A Java application collects garbage too often with System.gc () and I want to know why? Yes, please, just besides -XX:PreserveFramePointer will have to be included also -XX:+ExtendedDTraceProbes is a very expensive option that you can't keep on permanently. If you often ask the admin to turn it on and off - he can guess that you are not a real necromancer (in fact, you are worse - you are a javist, who will now bring out his brain). Well, after this hold hellish ritual, which tells Sasha: you will need to attach to method__entry .

In addition, Sasha will tell you what a perf bad (spoiler: pushes too much data for analysis in user space) and about all such things.

I highly recommend listening to and drawing conclusions from this report to absolutely everyone who is involved in the performance of a Java application on the GNU / Linux platform. This is an absolute must have .

2. Make Hibernate fast again

Speaker: Nikolay Alimenkov (EPAM); rating: 4.51 ± 0.04.

What ever will have to see Hibernate in the top reports in second place - it turned out to be a surprise, if not a shock. Hibernate is the kind of thing that was released in 2001 . Hasn't all been said about him for all these years? Are there any people who will listen to this?

Remained. But only if this is a really good report, and Nikolai Alimenkov is the very person who understands the varieties of Hibernate. Over the course of five years he has been making reports with holivorny names like “Why I hate Hibernate” or “Barefoot on the Hibernate Rake”, and so on - the list is long and some of them can be reviewed on YouTube .

I would like to say that the problem voiced in the title is really close to me. People use Hibernate incorrectly, refuse to think with the brain, do not read smart books, and then cry that “Hibernate is slowing down.” On the one hand, it causes such an unpleasant feeling, a cross between pity and snobish contempt. On the other hand, if the system has such an API, which with most users cannot master it for almost 17 years, there is clearly something wrong with such an API.

Nikolai in the first slide makes disclaimer on the topic that this is only his personal experience. But in this case, our experience is completely the same.

The report begins with a small obligatory introduction about what Hibernate is, what task it solves — the universal OOP adapter for all databases shows that Hibernate does not work magically, but inside it uses the same JDBC, JTA in the container and so Further. Looking at the whole chain of levels of abstraction, we understand that any part of it and any transition can influence the performance, and in order to improve them, we must be able to measure them.

For the measurement, it is proposed to use the logs of Hibernate itself ( hibernate.generate_statistics=true , the logger org.hibernate.stat at the DEBUG level, etc.) or write microbench marks on JMH .

In order to see which requests go to the database, it is proposed to use all sorts of datasource proxy (p6spy, datasource-proxy, etc.) and watch the raw data. You can put some counting interceptor - to calculate how many physical queries sent to the database. And of course, you can enable query logging in Hibernate itself.

Further Nikolay shows how much interesting can be subtracted in the Hibernate log of even a relatively small query. The log shouts and squeals that everything is wrong with you, and it is urgently necessary to redo it. (However, usually no one reads it until thunder breaks out.) Including the log tells how to read the statistics in the logs, where and for what the time was spent.

The report describes the main things that can and should be tune. , JDBC, connection pool — , . , JDBC Session.doWork(), .

, , . , N+1. - , «, N+1 — , », … , . . — : , , , NamedEntityGraph ( Hibnerate, JPA, ).