Why Does My System Freeze? 9 Common Causes and How to Diagnose Them

Introduction

Hello, I'm Tianlu. When a system suddenly hangs, a clear troubleshooting mindset is essential; otherwise you may panic.

The blockage often stems from underlying network or backend issues such as databases, middleware, or external interfaces.

This article discusses the aspects to consider when diagnosing system blockage and walks through a real case study.

1. Common causes of system blockage

Unlimited instantaneous concurrent requests from the frontend

Large file upload or export

Thread pool exhaustion

Memory leaks or overflow

Logical errors like infinite loops

Database connection pool saturation

Slow database queries (e.g., missing indexes)

Downstream services without timeout settings

Cache or message‑queue failures

1.1 Unlimited instantaneous concurrent requests

If users fire hundreds or thousands of identical requests in a short period, the backend thread pool can be instantly filled, causing the system to freeze. Therefore, rate‑limiting is usually required in system design.

1.2 Large file upload / export

Exporting massive data (e.g., over 100 k rows) blocks mainly during data processing and file generation. Loading all data at once can exhaust memory.

// Bad example: query 1 million rows at once
List<User> userList = userMapper.selectAll(); // assume 1 KB each → 1 GB total

With two such export requests, OOM may occur; even without OOM, massive object creation triggers frequent Young GC, increasing response latency from 100 ms to 1‑2 s.

Libraries like POI keep the whole document in memory; generating a 100 k‑row Excel can consume 500 MB‑1 GB and may cause full GC.

1.3 Thread pool exhaustion

Tomcat’s default max threads is 200. If average request handling time grows from 100 ms to 5 s, only ~40 requests per second can be processed; exceeding this leads to queuing and eventual rejection.

1.4 Memory leak / overflow

Unclosed I/O streams or static collections that grow indefinitely cause JVM memory to increase, leading to frequent long‑stop‑the‑world GC or OOM, manifesting as intermittent unresponsiveness.

1.5 Logical errors such as infinite loops

When an endpoint spawns a thread that runs an infinite loop, many threads consume CPU, quickly filling Tomcat’s thread pool; subsequent requests time out or receive no response, indicating system blockage.

1.6 Database connection pool saturation

If the pool (e.g., max 10 connections) is fully occupied and not released, new database operations wait indefinitely, causing slow responses or timeouts.

1.7 Slow database queries

Queries that run for tens of seconds (e.g., full table scans without indexes) lock connections, preventing their release. Multiple concurrent slow queries exhaust the pool, leading to timeouts for other requests.

@GetMapping("/slow-query")
public String slowQuery() {
    // Full table scan without index (assume 10 million rows)
    List<Map<String, Object>> result = jdbcTemplate.queryForList(
        "SELECT * FROM user WHERE create_time > '2023-01-01'"
    );
    return "Found " + result.size() + " rows";
}

1.8 Downstream service unresponsive without timeout

If a downstream endpoint crashes and the caller lacks a timeout, each request blocks a Tomcat thread forever. When the number of blocked threads reaches the pool limit, the whole system stalls.

1.9 Cache or message‑queue failure

When middleware like Redis crashes and the client has no timeout or fallback, each request hangs, eventually exhausting the thread pool and causing system‑wide blockage.

2. Our real‑world blockage investigation

Last month our system experienced a blockage. The investigation steps were:

Checked logs – request volume was normal, ruling out sudden spikes or attacks.

Verified no large file upload/export was occurring.

Monitored JVM – no memory leaks or OOM.

Reviewed slow‑SQL and connection‑pool metrics – nothing abnormal.

Confirmed Redis, Elasticsearch, RocketMQ responded normally.

Identified a downstream formatting service that never returned a response, suspecting missing timeout.

Finally we discovered the RestTemplate used for remote calls had no connection or read timeout configured, causing Tomcat threads to be held indefinitely when the downstream service failed.

@Autowired
private RestTemplate restTemplate;

JSONObject result = restTemplate.postForEntity(url, data, JSONObject.class).getBody();

@Configuration
public class RestemplateConfig {
    @Bean
    public RestTemplate restTemplate() {
        // Create request factory and set timeout parameters
        SimpleClientHttpRequestFactory requestFactory = new SimpleClientHttpRequestFactory();
        // Connection timeout: 3 seconds
        requestFactory.setConnectTimeout(3000);
        // Read timeout: 5 seconds (adjust as needed)
        requestFactory.setReadTimeout(5000);
        // Use the configured factory
        return new RestTemplate(requestFactory);
    }
}