Practical Data Structures and Algorithms for Java Developers From Fundamentals to Real-World Engineering (Mikhail Davidovich)（Z-Library）

Page 1

Practical Data Structures and Algorithms for Java Developers From Fundamentals to Real-World Engineering — Mikhail Davidovich

Page 2

Practical Data Structures and Algorithms for Java Developers From Fundamentals to Real-World Engineering Mikhail Davidovich

Page 3

Practical Data Structures and Algorithms for Java Developers: From Fundamentals to Real-World Engineering ISBN-13 (pbk): 979-8-8688-3012-9 ISBN-13 (electronic): 979-8-8688-3013-6 https://doi.org/10.1007/979-8-8688-3013-6 Copyright © 2026 by Mikhail Davidovich This work is subject to copyright. All rights are reserved by the Publisher, whether the whole or part of the material is concerned, specifically the rights of translation, reprinting, reuse of illustrations, recitation, broadcasting, reproduction on microfilms or in any other physical way, and transmission or information storage and retrieval, electronic adaptation, computer software, or by similar or dissimilar methodology now known or hereafter developed. Trademarked names, logos, and images may appear in this book. Rather than use a trademark symbol with every occurrence of a trademarked name, logo, or image we use the names, logos, and images only in an editorial fashion and to the benefit of the trademark owner, with no intention of infringement of the trademark. The use in this publication of trade names, trademarks, service marks, and similar terms, even if they are not identified as such, is not to be taken as an expression of opinion as to whether or not they are subject to proprietary rights. While the advice and information in this book are believed to be true and accurate at the date of publication, neither the authors nor the editors nor the publisher can accept any legal responsibility for any errors or omissions that may be made. The publisher makes no warranty, express or implied, with respect to the material contained herein. Managing Director, Apress Media LLC: Welmoed Spahr Acquisitions Editor: Melissa Duffy Development Editor: Laura Berendson Editorial Assistant: Gryffin Winkler Cover designed by eStudioCalamar Cover image designed by Julia Taubitz on Unsplash.com Distributed to the book trade worldwide by Springer Science+Business Media New York, 1 New York Plaza, New York, NY 10004. Phone 1-800-SPRINGER, fax (201) 348-4505, e-mail orders-ny@springer-sbm.com, or visit www.springeronline.com. Apress Media, LLC is a Delaware LLC and the sole member (owner) is Springer Science + Business Media Finance Inc (SSBM Finance Inc). SSBM Finance Inc is a Delaware corporation. For information on translations, please e-mail booktranslations@springernature.com; for reprint, paperback, or audio rights, please e-mail bookpermissions@springernature.com. Apress titles may be purchased in bulk for academic, corporate, or promotional use. eBook versions and licenses are also available for most titles. For more information, reference our Print and eBook Bulk Sales web page at http://www.apress.com/bulk-sales. Any source code or other supplementary material referenced by the author in this book is available to readers on GitHub. For more detailed information, please visit https://www.apress.com/gp/services/ source-code. If disposing of this product, please recycle the paper Mikhail Davidovich Tbilisi, Georgia

Page 4

To my family, who reminds me every day that learning never ends.

Page 5

(This page has no text content)

Page 6

(This page has no text content)

Page 7

(This page has no text content)

Page 8

(This page has no text content)

Page 9

ix About the Author Mikhail Davidovich is a Lead Java Engineer with more than 25 years of experience building scalable, high-performance systems using Java and related technologies. Throughout his career, he has worked on complex enterprise and distributed systems across multiple industries, focusing on performance, reliability, and maintainability. In addition to hands-on software development, Mikhail actively participates in technical mentoring, knowledge sharing, and engineering education. He regularly speaks on back-end architecture, distributed systems, and modern Java development topics, helping developers bridge the gap between theoretical concepts and real-world engineering challenges. Mikhail's expertise spans Java, Spring, cloud-native systems, microservices, distributed architectures, and performance optimization. Combining practical industry experience with a strong focus on engineering thinking, he brings a real-world perspective to the study of data structures and algorithms.

Page 10

xi About the Technical Reviewer Akash Kumar Athghara is a Senior Software Engineer II at Cisco ThousandEyes, where he works on enterprise platform engineering for data-intensive distributed systems and reliability. He has 9+ years of experience designing, modernizing, and operating back-end platforms that support enterprise-scale usage reporting, billing workflows, observability, multi-region operations, and customer-facing reliability. His work spans distributed systems architecture, performance optimization, disaster recovery, cloud-native service modernization, and resilient platform design. Before Cisco, Akash worked at Fujitsu Network Communications on Virtuora, a next-generation SDN controller, and contributed to OpenROADM MSA standards initiatives for interoperable optical networking systems. He holds an M.S. in Computer Engineering from San Jose State University. 

Page 11

xiii Acknowledgments Writing a book is never a solo effort. Many people contributed their time, expertise, encouragement, and support throughout this journey, and I would like to express my sincere gratitude to all of them. First, I would like to thank the publishing team for their guidance and support throughout the entire process. Special thanks to Melissa Duffy and Abirami D. S. for their coordination, feedback, and assistance in bringing this book to completion. I am deeply grateful to the technical reviewers who invested significant time and effort in improving this manuscript. In particular, I would like to thank Akash Kumar Athghara, the primary technical reviewer of this book, for his detailed feedback, thoughtful suggestions, and careful attention to technical accuracy. I would also like to thank Laura Berendson and Melissa Duffy for their valuable review comments and contributions, which helped make the content clearer, more accurate, and more useful for readers. A special thank you goes to my friend Maxim Bashurov, an exceptional technical writer, whose advice, discussions, and insights into technical communication helped shape many aspects of this book. His ability to explain complex ideas clearly has been a constant source of inspiration. I would also like to thank my friend Phillip Standard for reviewing parts of the manuscript and helping to improve the quality of the English text. His feedback, corrections, and suggestions significantly improved the readability and clarity of the book. My sincere thanks also go to my colleague Kseniya Yudzichava. Working alongside her provided valuable experience, perspectives, and professional insights that contributed to my growth as an engineer and influenced many of the ideas presented in this book. Finally, I would like to thank all colleagues, friends, mentors, and members of the Java community whose discussions, questions, and shared experiences helped me become a better engineer and author. Thank you all for being part of this journey.

Page 12

xv Introduction When developers hear the words data structures and algorithms, many immediately think of university courses, complex mathematical proofs, endless exercises with binary trees, or preparing for technical interviews. It often seems that algorithms exist separately from everyday software development and are only useful for people who want to pass interviews at large technology companies. In reality, the situation is very different. Almost every application we work with is built on data structures and algorithms. When a database uses an index to find records, when a cache speeds up a repeated request, when a collection stores objects in memory, when an event stream passes through a message queue, or when a search engine finds a document in a fraction of a second, all of these rely on the ideas behind data structures and algorithms. At the same time, most Java developers rarely need to implement a sorting algorithm, write their own hash table, or build a balanced search tree from scratch. Much more often, they need to choose between several possible solutions, understand the consequences of that choice, and evaluate how the system will behave as the amount of data and workload grows. That is why this book is not written as a reference guide to algorithms or as a collection of interview preparation exercises. Its goal is to show how algorithmic thinking helps engineers make better decisions in real Java projects. We will begin with the fundamental data structures and gradually move on to searching, sorting, trees, graphs, and optimization algorithms. Then we will take one more step and see how these ideas are applied when designing production systems. Throughout the book, we will continuously connect theory with practice. The Java Collections Framework, Spring Boot, databases, caching, and indexes are not presented as separate topics but as natural examples of how these concepts are used in real systems.

Page 13

xvi This book is not intended to teach you to memorize algorithms. It is far more important to understand why they work the way they do, what trade-offs are hidden behind each decision, and how to choose the approach that best fits the requirements of a particular system. If, after reading this book, you begin to see data operations behind business requirements, understand the reasoning behind architectural decisions, and feel more confident choosing the right data structures and algorithms, then this book has achieved its goal. InTroduCTIon

Page 14

1 © Mikhail Davidovich 2026 M. Davidovich, Practical Data Structures and Algorithms for Java Developers, https://doi.org/10.1007/979-8-8688-3013-6_1 CHAPTER 1 Algorithms for Java Developers Algorithms are one of the fundamental building blocks of software development. Every application, from a small utility to a large distributed system, relies on algorithms to process data, make decisions, and produce results. Yet many developers associate algorithms exclusively with technical interviews, programming competitions, or academic computer science courses. In reality, algorithms appear in everyday development work far more often than most people realize. Every time you sort a collection, search for a value, process incoming data, validate user input, or transform information, you are working with algorithms. Understanding how they work helps developers write more reliable, scalable, and maintainable software. This chapter introduces the foundations of algorithmic thinking. We will discuss what algorithms are, how they differ from code, why decomposition is essential when solving complex problems, and how flowcharts can be used to visualize and validate logic before implementation begins. The goal is not to memorize sophisticated algorithms, but to develop a systematic way of thinking about problems and solutions. The concepts introduced here will serve as a foundation for the rest of the book. In the following chapters, we will apply the same approach to concrete data structures and algorithms, gradually moving from simple examples to more advanced techniques used in real-world Java applications.

Page 15

2 What Algorithms Are in Real Life When many developers – especially beginners – hear the word “algorithms” in an interview, they start to feel noticeably nervous. And that is completely natural. The topic of algorithms itself seems complex, large, and “academic,” and at universities, it is indeed studied for several years as a separate subject. It is the foundation of computer science, and there are good reasons for that. But if we set aside fears, an algorithm is simply a finite sequence of well-defined steps used to solve a problem or achieve a specific result. Algorithms exist inside programs, regardless of the programming language or domain. Any program is a set of actions that must be performed to get a result. Yes, it really is that simple: a computer does not “understand” anything on its own; it only follows instructions. That is why any meaningful program has the same basic elements: input data → sequence of steps → result. And this “sequence of steps” is precisely what an algorithm is. An algorithm is not magic and not pure mathematics; it belongs more to the area of logic. It is a way to describe how exactly a program should arrive at the expected result. Very often, beginner programmers think that algorithms are something from the world of science or programming contests. In part, they are right. Algorithms do exist there as well. But the reality is that algorithms are something we all deal with every day in normal life: cooking a dish by a recipe, assembling IKEA furniture, finding the maximum element in an array, and processing input data. All of these are algorithms. Here, I want to emphasize one important thing: an algorithm is not code yet. And, accordingly, code is not an algorithm. These are two different things. Of course, they are related, but they are not the same. Code is a concrete implementation of an algorithm in a specific programming language: Java, C++, bash, and so on. Code is the syntax of a particular language – keywords, data types, operators, language-specific features, and formatting conventions. An algorithm is the logic, the idea, the meaning of what exactly should happen. It is a sequence of steps described in human language: what we take → what we check → what we do → what we return. An algorithm answers the question: “What steps need to be taken to achieve the desired result?” Chapter 1 algorithms for Java Developers

Page 16

3 Code answers the question: “How should these steps be written so that the computer understands them?” Beginners confuse these things most often. It seems that if you write code, you are writing an algorithm. But that is not true. Very often, people write code without having an algorithm at all. This leads to chaos in the head, strange bugs, endless fixes, debugging, nervous switching between files, dozens of print statements in the console – in short, a very typical picture. To avoid such situations, you need to learn to separate the idea from the implementation. First the algorithm – then the code. First understanding – then syntax. Otherwise, you get “code for the sake of code,” not a solution to the problem. Algorithms in Everyday Java Work Usually, the word “algorithm” brings associations like LeetCode, graphs, scary formulas, and interviews at big companies. In modern JDKs, Collections.sort() delegates to List.sort(). The default implementation uses a stable and adaptive sorting algorithm that performs efficiently on many real-world datasets, especially when the data is already partially ordered. Yes, you are not writing it by hand, but it still exists and affects performance. When you put something into a HashMap or HashSet, a hash table lookup happens under the hood – this is also an algorithm, and a quite smart one. When you traverse a JSON or XML tree, you are traversing a data structure. When you group, insert, or delete data, all of this is algorithms, whose implementation details are hidden behind library abstractions. What is funny is that most developers do these things automatically and do not even think of them as “algorithms.” But not knowing how things work inside can take revenge very quickly as an application grows. The list was small – everything was fast. The list grows to 200,000 elements – and suddenly it “hangs,” and you do not understand why. And quite often the reason is that the algorithm or data structure that used to work well for small datasets has become too expensive as the amount of data grows. Chapter 1 algorithms for Java Developers

Page 17

4 Algorithms are not about mathematical puzzles. They are about why your service works fast or slow, why one approach scales and another breaks, why one operation takes milliseconds, and another takes seconds. They help you make correct engineering decisions instead of blindly copying code from ChatGPT. And even if you are never going to interview at FAANG in your life, algorithms will still be useful. Because, in the end, your code will live in production, work with real data, and handle millions of requests under load. And in such moments, it is the understanding of algorithms (not magic annotations) that turns a developer into a real engineer. Eating the Elephant One Bite at a Time: How to Approach a Problem There is a popular riddle: How do you eat an elephant whole? If you ask this to a person outside the IT world, they will stop and think, because the task looks huge and impossible if you try to solve it “head on.” But if you have ever worked on big and complex tasks, you probably know the answer and the approach that works almost 100% of the time. This approach is called decomposition. What does it mean? It means that to solve a complex problem, you need to split it into parts. For example, how do you eat an elephant? Piece by piece. You break it into smaller parts and start eating. Only then can the task actually be done. In programming, such “elephants” appear every day. So, using decomposition, let’s try to understand how to build algorithms the right way. Here is the task: find the smallest sum of two numbers in an array of integers. When a task sounds large, your brain starts to panic. But if you break it into small steps, each step becomes simple and clear. First, you need to understand what the algorithm should do and what problem it solves. In our case, it is obvious: find the smallest possible sum. The next step is: What does the algorithm need to solve this task – what are the input parameters? In our case, the input is an array of integers. The next question you must answer is: What are the output parameters? The output is a single integer – the minimum sum. In Java, it is also important to think about numeric ranges. If the array may contain very large values, the sum of two int values can overflow. In such cases, using long for intermediate calculations may be more appropriate. Chapter 1 algorithms for Java Developers

Page 18

5 It may seem that this is all we need, and we can move on and start writing code, but not yet. We almost forgot about constraints and edge cases. These are two terms that people often confuse. Constraints are the rules of the task within which it must be solved: for example, the maximum number of elements in the input array, the type of elements (in our case, integer input data), limits on execution time, memory limits, and so on. Very often, constraints affect the choice of the algorithm. Constraints force you to think: Can we solve it faster? Can we scan the array only once? Do we really need sorting here, or can we do without it? Edge cases are special input cases that can break the algorithm. For example, an empty array is passed in, or otherwise, an array with the maximum possible number of elements, or an array where all elements are the same, or negative, and so on. The algorithm must be able to “digest” such inconvenient cases too. It is like entering the wrong Wi-Fi password: the router shows an error message, but it does not break because of it. So, we have defined: what the algorithm does, what its inputs and outputs are, what constraints exist, and what edge cases we must handle. Is everything ready to start writing code? And this is exactly where 90% of beginners make the same mistake: they open the IDE and start coding. But do they really understand what should happen step by step? That step-by-step plan is the nutshell of any algorithm. Of course, you can start coding – but it is better to read the following paragraph first, and then decide. At this stage, you really want to start writing code. Everything seems simple, and you want to finish the task as quickly as possible and see the result. But what happens next? Since there is still no clear structure in your head, the code gets rewritten several times. You write a loop inside another loop and no longer remember why you started writing the first one. You add logs, debug, rewrite pieces again and again, and it feels like the answer is just about to come together – but it does not. And then you want to delete everything and start from scratch. Sounds familiar? Be honest – who has been there? As a result, you may end up with a spaghetti monster that even its creator has trouble understanding. And I am not even talking about another person who sees it for the first time and may turn gray before understanding its logic. Why does this happen? Because the brain is trying to understand the problem and implement it at the same time. But these are two different modes, and they should not run in parallel – they should go one after the other. In the end, a person tries to think, write code, and debug at the same time, in a single flow. It is like trying to brush your teeth, eat breakfast, and read email all at once. Chapter 1 algorithms for Java Developers

Page 19

6 It is important to understand that an algorithm is a sequence of steps, a logic, while code is just a way to write down those steps. Until these steps are clear, the code becomes unstructured, fragile, and dependent on random decisions (remember edge cases). It is tough for the brain to hold all this complexity at the same time, so you first need to break the task into its components. When the steps are clear, the code is written almost automatically. Of course, implementation still involves engineering decisions. In Java, developers must choose appropriate data types, collections, error-handling strategies, and tests. However, once the algorithm is understood, these implementation decisions become much easier to make correctly. You no longer think about the algorithm, only about syntax. Agreed, it is much easier to keep one task in your head than many at once. The implementation becomes simple, complexity disappears, debugging is no longer a big problem, and most importantly, you can easily explain this algorithm to another developer. How do you know that it is still too early to start coding? If the symptoms described above are present, you cannot explain the algorithm to a colleague, you fix something in one place but break it in another, you constantly change the code but cannot get the desired result. But most importantly, if you cannot yet describe the solution in words, then it is too early to start coding. The conclusion is obvious: before you start writing code, you need first to build it in your head, and coding is the very last step. First understanding → sequence of steps → writing code. That is precisely why we talked earlier about decomposition and breaking the problem into parts. Code is the form of already thought-out logic, not a tool for discovering it. Algorithmic Thinking: Turning a Problem into Steps A typical beginner question is: “Okay, I understand that I need steps – but what steps exactly?” This is one of the key questions. The ability to answer it comes from the skill of algorithmic thinking. Writing algorithms is just a skill that is trained through repeated practice – like running, swimming, or driving a car. It is the skill of translating a task into a sequence of actions. Algorithmic thinking is not about knowing specific algorithms (although knowledge, of course, helps). It is the ability to see the problem, identify the necessary steps, understand their order, and recognize their dependencies. Most people look for a way to solve a problem, but the real power is in the ability to find the correct sequence of Chapter 1 algorithms for Java Developers

Page 20

7 actions. And probably the most critical question in algorithmic thinking is: what should happen first, what should happen next, and what should happen at the end. This question seems simple, but it is fundamental. If the reader learns it, they will become much stronger at solving problems. In fact, any algorithm can be reduced to three main things: actions, answering “what do we do”; conditions, answering “when do we do it”; and repetitions, answering “how many times do we do it.” Everything else is basically a combination of these. At the same time, control flow is only part of the picture. The choice of data representation is equally important. Arrays, lists, hash tables, trees, and graphs often determine the efficiency of an algorithm just as much as the sequence of actions itself. This is a universal constructor for all algorithms. Even the most complex graphs and dynamic programming algorithms can be built using these pieces. Let’s look at a simple example – finding the minimum element in an array – and try to break the solution into steps. One possible version is • Take the first element of the array as a temporary minimum (action) • Iterate through the array (repetition) • Take the current element of the array (action) • Compare it with the temporary minimum; if it is smaller, assign the current value to the temporary minimum (condition and action) • Return the result (action) In essence, the core of any algorithm is a set of simple, small steps. There is no magic here. Try to write the steps yourself. Below are several tasks from simple to more difficult. Write the algorithm as steps. Try to describe it in simple actions, but if you get stuck, you can look at the solution at the end of the book. 1. Sum of powers of two Decompose a number into a sum of powers of two. For example, given 13, the decomposition is 8 + 4 + 1. Given 21, the decomposition is 16 + 4 + 1. Chapter 1 algorithms for Java Developers