Java Backend: One Year of Experience and Technical Summary (Part 1)

Java Backend: One Year of Experience and Technical Summary (Part 1)

1. Introduction

After graduating, I have spent over a year in development, grateful to technical managers and colleagues for their support, learning many things. I have encountered pitfalls, challenges, and the frustration of frequently being the fire‑fighter for system maintenance and releases.

During this year I realized many previous misconceptions, such as:

Collecting a lot of material and videos, filling up hard drives, and feeling satisfied without actually applying the knowledge.

Neglecting fundamentals, assuming that basic concepts are unnecessary, while many details remain unclear; every result in programming has a cause.

Aiming too high—wanting to design architecture, distributed systems, or big‑data solutions without a solid foundation.

Ignoring performance, focusing only on functionality, without considering SQL optimization, algorithmic improvements, or object cleanup.

Overlooking extensibility, tightly coupling modules, not extracting common utilities, and creating chaotic call relationships.

... (the list continues) ...

The article will now focus on the core technical points.

2. Syntax Basics

2.1 Java Class Initialization Order

The complete initialization sequence is: parent static fields → parent static blocks → child static blocks → parent instance fields → parent instance blocks → parent constructor → child instance fields → child instance blocks → child constructor.

2.2 Value Passing and Reference Passing

Many developers overlook this topic. Using a simple example, consider what elements remain in fatherList after the code runs.

Images illustrate basic value vs. reference passing and the surprising behavior of StringBuffer compared to String. Reviewing the source of String helps understand its memory allocation.

2.3 Collection Usage

Collections are ubiquitous. Understanding Set uniqueness, List ordering, Map key‑value pairs, and sorted variants (TreeSet/TreeMap) enables clever solutions to complex problems.

2.3 Exception Handling

1. Using try, catch, finally is straightforward, but combining with transaction propagation can become very complex.

2. finally does not always execute; returning inside catch / finally is worth experimenting with.

3. Custom exceptions can be re‑thrown from catch and later captured by aspects for unified handling.

2.4 Object‑Oriented Concepts

Abstract, encapsulation, inheritance, and polymorphism are well known, but applying them effectively in projects requires experience.

Common patterns include creating base classes for controllers (e.g., a method to obtain the logged‑in user ID) and generic DAO base classes for CRUD operations.

Polymorphic override allows a base‑class reference to point to a subclass instance, invoking the subclass implementation—frequently used in the Strategy pattern.

Design patterns such as Strategy and Singleton are essential topics for interviews.

3. Multithreading

3.1 Thread Safety

Thread safety is a frequent source of bugs. Key points include:

Shared variables must be synchronized.

Concurrent updates to the same database row from different modules can cause race conditions.

Unsafe types (e.g., StringBuffer, HashMap) should be avoided in concurrent contexts.

Spring beans are singleton by default; mutable class fields must be handled carefully.

Multiple systems sharing a database introduce distributed‑system‑like issues.

Duplicate user submissions must be guarded against even when database checks exist.

3.1.1 Thread‑Safety Problems

Details of the problems listed above.

3.1.2 Thread‑Safety Solutions

Use safe types, Java lock mechanisms ( synchronized, Lock, ReentrantLock, wait/notify), the java.util.concurrent package, database row locking, or middleware such as Zookeeper for distributed coordination.

3.2 Asynchronous Execution

Asynchronous tasks are useful for I/O‑heavy or third‑party services (SMS, push, cloud storage). When many async tasks exist, a task queue (e.g., Redis‑based) should be employed.

3.3 Thread Communication

Methods include shared variables, message queues, and lock‑based busy‑waiting.

3.4 Thread Implementation

1. Extend Thread and override run(), then call start(). 2. Implement Runnable, create a Thread with the runnable instance. 3. Implement Callable, wrap with FutureTask for asynchronous results. Additional notes:

Understand Thread.join(). volatile does not guarantee thread safety.

After sleep, a thread is not guaranteed immediate CPU access. ThreadLocal provides per‑thread variable copies.

4. Open‑Source Frameworks

4.1 Hibernate & MyBatis

Key points include:

Hibernate first‑level (Session) and second‑level caches; second‑level cache can cause concurrency issues.

Understanding lazy loading.

Differences among get, load, save, persist, saveOrUpdate.

Session relationship handling (detached vs. persistent).

Spring Data integration and annotation‑based entity configuration.

MyBatis plugins and pagination.

Connection‑pool techniques.

4.2 Spring IOC

4.2.1 Spring Bean

1. Bean injection via annotations or XML for third‑party resources (DB connections, Jedis pool, etc.). 2. Bean scopes: Singleton, Prototype, Request, Session, Global Session. 3. Bean lifecycle (illustrated by an image).

4.3 Spring AOP

Core concepts: aspect, pointcut, joinpoint, advice, weaving, introduction.

Supported advice types: MethodBeforeAdvice, AfterReturningAdvice, ThrowsAdvice, MethodInterceptor, IntroductionInterceptor.

Implementation approaches:

Proxy‑based AOP.

Annotation‑driven @Aspect (recommended for readability and maintainability).

Pure POJO aspects.

Injection‑based aspects.

4.4 Spring Transaction

4.4.1 Transaction Propagation

Ensures atomicity; if an error occurs, the transaction rolls back. Propagation determines how inner transactions behave.

PROPAGATION_REQUIRED – join existing or create new (most common).

PROPAGATION_SUPPORTS – join if exists, otherwise non‑transactional.

PROPAGATION_MANDATORY – must have an existing transaction, else exception.

PROPAGATION_REQUIRES_NEW – always start a new transaction, suspending the current one.

PROPAGATION_NOT_SUPPORTED – execute non‑transactionally, suspending any existing transaction.

PROPAGATION_NEVER – must not run within a transaction.

4.4.2 Transaction Isolation Levels

ISOLATION_DEFAULT – uses the database’s default.

ISOLATION_READ_UNCOMMITTED – allows dirty reads.

ISOLATION_READ_COMMITTED – prevents dirty reads.

ISOLATION_REPEATABLE_READ – prevents dirty and non‑repeatable reads, may allow phantom reads.

ISOLATION_SERIALIZABLE – highest isolation, prevents dirty, non‑repeatable, and phantom reads.

4.5 Other Spring Technologies

Spring Boot for lightweight startup, Spring Security for role‑based access, Spring Task for scheduled jobs (beware of uncaught exceptions), Spring Data for entity mapping, Spring MVC for request handling, RESTful conventions, Spring Shell for command‑line operations.

5. Web Basics

5.1 Web Container Startup

web.xml loading order: listener → filter → servlet. Detailed startup process can be found in external tutorials.

5.2 Servlet, Interceptor, Listener, Filter

Servlet – handles request/response. Interceptor – implements HandlerInterceptor, similar to AOP, used for logging, security, monitoring. Listener – for events such as online‑user counting. Filter – modifies request/response before/after controller processing; can be used for encryption, etc.

5.3 Project Structure

5.3.1 Maven Structure

Familiarity with common Maven project layouts.

5.3.2 Maven Dependency Management

Keep version numbers centralized, use Spring milestone packages to resolve conflicts, and analyse dependencies with mvn dependency:tree (exclude transitive conflicts).

5.3.3 Version Control

Git, SVN, conflict resolution strategies, branch management (feature branches, hot‑fixes, etc.).

5.4 HTTP Requests

5.4.1 Request Methods

Common methods: POST, GET, PUT, HEAD, DELETE (others include COPY, MOVE, CONNECT, LINK, PATCH).

5.4.2 Headers and Status Codes

Typical request headers: Accept, Accept‑Charset, Content‑Type. Typical response headers: Content‑Type, Content‑Length, etc.

6. System Architecture

Experience mainly with server master‑slave setups and Nginx reverse‑proxy configuration.

Multiple project Nginx configs, Spring MVC JSON interaction, custom response wrappers, exception handling via aspects, duplicate‑submission prevention using session IDs stored in Redis, unit and performance testing, aspect‑based date/permission handling, caching.

7. NoSQL

1. Redis Java client Jedis, pool configuration, used for task queues and caching. 2. Neo4j graph database for social/recommendation features.

8. Server

Linux (CentOS) command‑line proficiency: ssh, vim, scp, ps, grep, sed, awk, cat, tail, df, top, chmod, tar, find, wc, ln, pipelines, etc.

Server components: JDK, Tomcat, Nginx, MySQL, Jedis, Neo4j; firewall issues with Nginx noted.

Monitoring CPU, disk, memory, locating PIDs, log inspection, load balancing with Nginx, automated deployment scripts, simple shell scripting, alerting on fatal exceptions or metric thresholds.

9. Database Related

(Section placeholder – details omitted in source.)

10. Third‑Party API Integration

10.1 Payment

WeChat Pay required extensive configuration (about two weeks). Alipay integration was completed in two days.

10.2 Push Notifications

Define tags and aliases for users; ensure synchronization when data changes; asynchronous implementation improves user experience.

10.3 Cloud Storage

File uploads to cloud services (e.g., Qiniu), remember to create buckets.

10.4 SMS Verification

Simple third‑party integration: add dependency, call API, configure templates and request limits.

10.5 Email

Simple utility class for sending emails.

Java learning exchange QQ group: 523047986 – no off‑topic chat, please join only if interested.

Please scan the QR code on the right to get more Java resources.