Java Interview Insights: Spring Boot Startup, Spring MVC Flow, MySQL Indexes, and Redis Performance

The article recounts a recent Hikvision interview, outlining campus salary ranges and providing a technical Q&A that explains Spring Boot’s startup sequence, Spring MVC request handling, MySQL index structures, creation rules, and performance diagnostics, as well as Redis’s in‑memory, single‑threaded architecture and optional I/O threading.

Java Tech Enthusiast
Java Tech Enthusiast
Java Tech Enthusiast
Java Interview Insights: Spring Boot Startup, Spring MVC Flow, MySQL Indexes, and Redis Performance

This article shares a recent interview experience at Hikvision, including salary ranges for campus recruitment and a technical Q&A covering Java, MySQL, and Redis.

Java

Spring Boot startup process

Locate the main method and create a SpringApplication instance.

Enter run(), which registers SpringApplicationRunListeners.

Load the ConfigurableEnvironment and add it to the listeners.

Load the ConfigurableApplicationContext which becomes the return value of run().

Create the Spring container, refresh the context, and perform auto‑configuration and bean instantiation.

Spring MVC execution flow

Client request reaches the front‑controller DispatcherServlet. DispatcherServlet uses HandlerMapping to locate a matching handler.

The handler and any interceptors are wrapped in a HandlerExecutionChain. DispatcherServlet finds a suitable HandlerAdapter and invokes the handler.

The handler returns a ModelAndView object. DispatcherServlet processes the view name via ViewResolver and renders the view.

MySQL

Indexes are classified from four perspectives:

Data structure: B+Tree, Hash, Full‑text.

Physical storage: clustered (primary) and secondary indexes.

Field characteristics: primary, unique, normal, prefix.

Number of columns: single‑column and composite indexes.

Key points:

InnoDB uses B+Tree for both primary and secondary indexes.

Primary key becomes the clustered index; if absent, the first NOT NULL unique column is used, otherwise an implicit auto‑increment column is created.

Secondary indexes store only the primary‑key value, so queries that can be satisfied from the secondary index avoid a table lookup (covering index).

Common index creation statements (kept unchanged):

CREATE TABLE table_name (
  ...
  PRIMARY KEY (index_column_1) USING BTREE
);
CREATE TABLE table_name (
  ...
  UNIQUE KEY (index_column_1, index_column_2, ...)
);
CREATE UNIQUE INDEX index_name ON table_name(index_column_1, index_column_2, ...);
CREATE TABLE table_name (
  ...
  INDEX(index_column_1, index_column_2, ...)
);
CREATE INDEX index_name ON table_name(index_column_1, index_column_2, ...);
CREATE INDEX index_product_no_name ON product(product_no, name);

When using composite indexes, the left‑most prefix rule applies: the index can be used only if the query predicates start with the leftmost column(s). Queries that violate this rule (e.g., filtering only on the second column) cause index loss.

Typical reasons for index loss include:

LIKE patterns with a leading wildcard (e.g., %value).

Applying functions or expressions to indexed columns.

Implicit type conversion between strings and numbers.

OR conditions where only one side uses an indexed column.

Use EXPLAIN to inspect the execution plan. Important fields: possible_keys: indexes that could be used. key: the actual index used (NULL means none). key_len: length of the used index. rows: number of rows examined. type: scan type (All, index, range, ref, eq_ref, const) ordered from worst to best.

Additional extra flags such as Using filesort, Using temporary, and Using index indicate sorting, temporary tables, or covering index usage respectively.

Redis

Redis achieves high performance because most operations run entirely in memory using efficient data structures, and a single‑threaded event loop avoids context‑switch overhead and lock contention.

It employs I/O multiplexing (select/epoll) to handle many client sockets with one thread.

Since version 6.0, Redis adds optional I/O worker threads to parallelize network I/O while keeping command execution single‑threaded.

Background threads handle costly tasks such as file closing, AOF flushing, and lazy memory freeing.

// Enable I/O threads for read requests
io-threads-do-reads yes
// Configure the number of I/O threads (total threads = io-threads, one is the main thread)
io-threads 4

Guidelines suggest using 2–3 I/O threads on a 4‑core CPU and up to 6 on an 8‑core CPU, always keeping the thread count lower than the core count.

Original Source

Signed-in readers can open the original source through BestHub's protected redirect.

Sign in to view source
Republication Notice

This article has been distilled and summarized from source material, then republished for learning and reference. If you believe it infringes your rights, please contactadmin@besthub.devand we will review it promptly.

BackendjavaredismysqlinterviewSpringBoot
Java Tech Enthusiast
Written by

Java Tech Enthusiast

Sharing computer programming language knowledge, focusing on Java fundamentals, data structures, related tools, Spring Cloud, IntelliJ IDEA... Book giveaways, red‑packet rewards and other perks await!

0 followers
Reader feedback

How this landed with the community

Sign in to like

Rate this article

Was this worth your time?

Sign in to rate
Discussion

0 Comments

Thoughtful readers leave field notes, pushback, and hard-won operational detail here.