1. 项目概述：Java安全为何成为焦点

最近在排查线上服务时，又遇到了一个因第三方库漏洞导致的告警。这让我想起，无论是社区讨论还是安全团队的周报，“Java应用漏洞”似乎总是一个高频词。从经典的序列化漏洞到近年频发的日志框架、依赖组件问题，Java生态的庞大和复杂，在带来开发便利的同时，也埋下了不少安全隐患。很多开发者，包括曾经的我，都抱有“用了主流框架就安全了”或者“我们业务简单，黑客看不上”的侥幸心理。但现实是，自动化攻击工具可不管这些，它们会无差别地扫描全网，利用那些众所周知的漏洞尝试入侵。今天，我们就抛开那些宽泛的安全原则，直接深入到代码和配置层面，剖析五类在Java应用中最为常见、也最高危的漏洞。我的目标不是让你成为安全专家，而是帮你建立起“免疫系统”，知道漏洞从哪来，该如何发现，以及最关键的——如何用最小成本修复它。

2. 第一类高危漏洞：不安全的反序列化

这可以说是Java领域“经久不衰”的漏洞之王，其根源在于Java对象序列化机制的设计初衷是方便网络传输或持久化，但并未充分考虑将不受信的数据还原成对象时的危险性。

2.1 漏洞原理：当“数据”变成“代码”

简单来说，序列化是把一个对象的状态信息转换成可以存储或传输的形式（字节流），反序列化则是将这个字节流还原成对象。漏洞就出在反序列化过程中：Java在还原对象时，会递归地调用对象的 readObject 方法。如果攻击者精心构造了一个恶意的序列化字节流，其中包含了对某些危险类（如 Runtime.exec ）的调用链，那么反序列化时，就会像执行代码一样执行这些操作，从而实现远程命令执行。

最典型的例子就是Apache Commons Collections库（3.x, 4.x版本）的反序列化利用链（即常说的CC链）。即使你的业务代码没有直接使用这个库，但只要你的应用Classpath里存在这个库（很多框架会间接依赖），攻击者就有可能利用它。

注意：不要以为你的应用没有对外提供反序列化接口就高枕无忧。很多RPC框架（如Hessian, Dubbo）、消息队列（如Kafka消息体）、缓存（如Redis存储的特定格式数据）甚至HTTP请求参数（某些框架配置不当时）都可能成为反序列化的入口点。

2.2 实战场景与攻击向量

  1. HTTP请求参数 ：早期某些Web框架允许通过HTTP参数传递序列化对象，攻击者可以直接在请求中植入恶意字节流。
  2. RPC通信 ：使用Java原生序列化或基于其的协议（如RMI）进行服务间调用时，如果服务端对客户端身份验证不严，攻击者可以伪装客户端发送恶意请求。
  3. 消息队列 ：消费者从队列中取出消息并进行反序列化处理，如果消息生产者被攻破或消息被篡改，恶意消息就会被执行。
  4. 文件与数据库 ：从不受信的来源读取序列化文件或从数据库字段中读取序列化数据并还原。

我曾审计过一个内部系统，它接收外部上传的“配置文件”（一个序列化的Java对象），然后直接进行 ObjectInputStream.readObject() 。这相当于给攻击者敞开了一扇大门。

2.3 修复与防护方案

完全杜绝反序列化风险很难，但可以将其降到最低：

  1. 首选方案：替换序列化协议

    • 彻底弃用 Java原生序列化（ java.io.Serializable ）。对于新的系统，这应该作为一条铁律。
    • 转向安全的替代方案 ，如JSON（Jackson, Gson）、Protocol Buffers、Kryo（需正确配置）、或Hessian的安全模式。这些格式通常不直接支持执行任意代码。

  2. 白名单校验（如果必须使用Java原生序列化） 如果历史包袱太重无法更换，必须实施严格的反序列化过滤器。从Java 9开始，提供了 ObjectInputFilter API，在Java 8中可以通过Agent或类似 SerialKiller 的库实现。

    // Java 9+ 示例：设置一个只允许特定类的过滤器
ObjectInputFilter filter = ObjectInputFilter.allowFilter(
    cl -> cl.getPackageName().equals("com.yourcompany.safe.model"),
    ObjectInputFilter.Status.REJECTED);
ObjectInputStream ois = new ObjectInputStream(inputStream);
ois.setObjectInputFilter(filter);
YourObject obj = (YourObject) ois.readObject();

    白名单的维护是关键，需要梳理所有合法的、需要序列化的业务模型类。

  3. 升级与隔离依赖

    • 及时升级已知存在危险利用链的第三方库，如Apache Commons Collections到最新版（其新版已修复了相关类的构造方法）。
    • 对于无法升级的旧系统，可以考虑使用 SerialKiller 这样的安全包装库，或者在JVM层面使用安全管理器（ SecurityManager ）进行限制（但配置复杂）。

  4. 输入源可信验证 确保进行反序列化的数据来源是可信的，例如通过数字签名验证数据的完整性和来源身份。

3. 第二类高危漏洞：表达式注入（EL/SpEL/OGNL）

表达式注入漏洞让攻击者能够将恶意表达式“注入”到程序原本的表达式解析逻辑中，从而窃取数据、执行逻辑甚至命令。这在Java Web开发中尤为常见。

3.1 漏洞原理：当“表达式”失控

许多框架为了提供动态、灵活的功能，内置了表达式解析引擎：

  • EL (Expression Language) ： JSP和JSF的标准，用于在视图层访问数据。
  • SpEL (Spring Expression Language) ： Spring框架强大的表达式语言，用于@Value注解、Spring Security配置、XML配置等。
  • OGNL (Object-Graph Navigation Language) ： Struts2框架默认使用的表达式语言。

漏洞产生的根本原因是： 将用户可控的、未经净化的数据，直接拼接到动态表达式字符串中，并交给引擎执行。 引擎在执行时，会按照其语法权限去解析，如果攻击者输入的不是预期的简单属性名（如 user.name ），而是一段恶意表达式（如 T(java.lang.Runtime).getRuntime().exec('calc') ），就会造成严重危害。

3.2 典型场景：Spring Boot Actuator与SpEL

Spring Boot Actuator端点如果配置不当（如未授权访问），其中的某些功能可能成为SpEL注入的点。一个历史著名漏洞CVE-2017-8046，就是通过HTTP请求的 PATCH 方法，在JSON补丁操作中注入SpEL表达式。

// 恶意PATCH请求体示例（历史漏洞，已修复）
[
  { "op": "replace", "path": "T(java.lang.Runtime).getRuntime().exec('touch /tmp/hacked')", "value": "hacked" }
]

path 参数的值被直接传入SpEL解析器，导致命令执行。

3.3 修复与防护方案

  1. 绝对禁止用户输入直接参与表达式解析 这是最根本的原则。任何需要动态解析的地方，都应该使用白名单机制，或者将用户输入严格限制为“数据”而非“表达式结构”。

  2. 使用安全的表达式上下文

    • 对于SpEL，创建 StandardEvaluationContext 时，避免使用根对象为 null 或过于强大的类型。更安全的是使用 SimpleEvaluationContext ，它仅支持基本的属性访问和方法调用，默认禁用了Java类型引用（ T() ）、构造函数调用等危险功能。
    // 不安全的方式（StandardEvaluationContext 功能强大）
// ExpressionParser parser = new SpelExpressionParser();
// StandardEvaluationContext context = new StandardEvaluationContext(dataObject);
// String result = parser.parseExpression(userInput).getValue(context, String.class);

// 安全的方式（SimpleEvaluationContext 限制功能）
ExpressionParser parser = new SpelExpressionParser();
SimpleEvaluationContext context = SimpleEvaluationContext.forReadOnlyDataBinding().build();
// 此时，userInput如果包含T(Runtime).exec()将会解析失败
String result = parser.parseExpression(userInput).getValue(context, dataObject, String.class);

  3. 框架安全配置

    • Spring Security ： 确保Actuator端点（如 /env , /refresh ）受到严格的访问控制，生产环境建议禁用或通过内部网络访问。
    • Struts2 ： 及时升级到最新版本，历史版本中存在大量OGNL注入漏洞。配置 struts.ognl.excludedClasses 和 struts.ognl.excludedPackageNames 来限制OGNL可以访问的类。
    • 及时关注并使用最新稳定版本的框架，官方会修复已知的表达式注入漏洞。

  4. 代码审计与白盒测试 在代码审查时，重点关注所有使用了 SpelExpressionParser 、 OgnlUtil 等类的地方，检查其输入是否用户可控。使用静态代码分析工具（SAST）可以帮助发现这类问题。

4. 第三类高危漏洞：依赖组件漏洞（供应链攻击）

现代Java应用严重依赖开源组件（Maven/Gradle依赖），一个应用动辄引入上百个第三方库。这些库中的任何一个出现高危漏洞，都会让你的应用暴露在风险之下。这就是典型的供应链攻击。

4.1 漏洞原理：你信任的“伙伴”可能被利用

你并未直接编写有漏洞的代码，但你的依赖项中包含了有漏洞的代码。攻击者利用这些漏洞，可以与你直接利用应用漏洞达到同样的效果。例如：

  • Log4j2 (CVE-2021-44228) ： 这个“核弹级”漏洞就属于此类。攻击者通过构造特定的日志消息，即可触发JNDI注入，远程加载并执行恶意代码。问题的核心在 log4j-core 这个依赖里。
  • Fastjson (多个历史CVE) ： 这个常用的JSON解析库，在自动类型反序列化（ autoType ）特性上多次出现高危漏洞，可导致远程代码执行。
  • Apache Commons Text (CVE-2022-42889) ： 字符串替换功能存在递归解析，可能导致任意代码执行。

4.2 实战影响与排查困境

这类漏洞的可怕之处在于：

  1. 隐蔽性强 ： 开发者通常不会深入审查所有依赖库的代码。
  2. 影响面广 ： 一个基础库的漏洞可能影响成千上万的应用。
  3. 排查复杂 ： 依赖传递性导致漏洞库可能被深层间接引用， mvn dependency:tree 看到的树可能非常庞大，需要精准定位。

我记得Log4j2漏洞爆发时，我们首先用 mvn dependency:tree | findstr log4j 快速定位项目中的Log4j2版本，然后发现不仅直接依赖，更多是通过 spring-boot-starter-logging 等Starter间接引入的。

4.3 修复与防护方案：建立依赖管控流程

  1. 自动化漏洞扫描（左移）

    • 在CI/CD流水线中集成依赖漏洞扫描工具，如 OWASP Dependency-Check 、 Snyk 、 GitHub Dependabot 或 Trivy 。
    • 配置构建失败策略：当发现高危（Critical）或严重（High）漏洞时，中断构建，强制修复。
    # 使用OWASP Dependency-Check示例
mvn org.owasp:dependency-check-maven:check -DfailBuildOnCVSS=7

  2. 维护准确的依赖清单（SBOM）

    • 使用 mvn dependency:tree -DoutputFile=dependencies.txt 或Gradle的 dependencies 任务定期生成依赖树报告。
    • 考虑生成软件物料清单（SBOM），如SPDX或CycloneDX格式，这有助于在漏洞爆发时快速进行影响面分析。

  3. 依赖升级与降级策略

    • 定期升级 ： 不要长期使用旧版本依赖。制定计划，定期（如每季度）审查和升级主要依赖项。
    • 精准升级 ： 当某个库出现漏洞时，优先尝试升级该库到已修复的版本。如果因为兼容性问题无法升级直接依赖，查看是否有可升级的间接依赖路径，或者使用Maven的 <exclusions> 标签排除有漏洞的传递依赖，然后显式引入安全版本。
    <dependency>
    <groupId>org.springframework.boot</groupId>
    <artifactId>spring-boot-starter-web</artifactId>
    <exclusions>
        <exclusion>
            <groupId>org.apache.logging.log4j</groupId>
            <artifactId>log4j-core</artifactId>
        </exclusion>
    </exclusions>
</dependency>
<dependency>
    <groupId>org.apache.logging.log4j</groupId>
    <artifactId>log4j-core</artifactId>
    <version>2.17.2</version> <!-- 安全版本 -->
</dependency>
    • 漏洞缓解 ： 在紧急情况下，如果无法立即升级，可以寻求临时缓解措施。例如Log4j2漏洞初期，可以通过设置系统属性 log4j2.formatMsgNoLookups=true 或移除 JndiLookup 类文件来临时防护。但这只是权宜之计。

  4. 使用可信源与签名验证

    • 配置内部Maven仓库代理（如Nexus、JFrog Artifactory），并从官方或可信源同步依赖。
    • 启用依赖签名验证（虽然Java生态对此支持不如其他语言普遍，但一些关键库开始提供）。

5. 第四类高危漏洞：配置不当导致的信息泄露与越权

很多安全问题并非源于代码bug，而是错误的配置。这些配置可能存在于应用配置文件、应用服务器设置或云平台环境中。

5.1 漏洞原理：默认不安全与过度暴露

框架和中间件为了便于开发和调试，通常会提供一些“强大”的功能和“宽松”的默认配置。直接将这些配置用于生产环境，就是灾难。

  1. 敏感信息泄露 ：

    • 异常信息泄露 ： 将完整的异常堆栈（包含SQL语句、文件路径、内部类名）直接返回给前端用户。
    • 调试接口暴露 ： Spring Boot Actuator的 /heapdump , /trace , /env 端点未授权访问，泄露内存信息、请求跟踪、环境变量（可能含密码）。
    • 目录遍历 ： 静态资源处理配置不当，允许通过 ../ 等路径遍历读取服务器上任意文件（如 /static/../../etc/passwd ）。

  2. 安全功能缺失或弱配置 ：

    • 未启用或弱化的安全头 ： 缺少 Content-Security-Policy (CSP)、 X-Content-Type-Options 、 X-Frame-Options 等HTTP安全头，导致跨站脚本（XSS）、点击劫持等风险增加。
    • 弱密码或默认密码 ： 数据库、Redis、管理后台使用弱口令或默认口令（如admin/admin）。
    • CORS配置过于宽松 ： 将 Access-Control-Allow-Origin 设置为 * ，允许任意网站跨域访问你的API，可能导致CSRF攻击或敏感数据泄露。

5.2 实战场景：一个Spring Boot应用的“裸奔”配置

假设一个刚入门的开发者创建了一个Spring Boot应用，为了图省事，使用了如下配置 application.yml ：

spring:
  datasource:
    password: root # 使用弱密码
management:
  endpoints:
    web:
      exposure:
        include: "*" # 暴露所有Actuator端点
  endpoint:
    health:
      show-details: always # 健康检查显示所有细节
server:
  error:
    include-stacktrace: always # 始终包含异常堆栈

这个应用一旦上线，攻击者可以通过 /actuator/env 看到所有配置（包括数据库密码），通过 /actuator/heapdump 下载内存快照分析敏感数据，任何程序错误都会将内部信息完整展示。

5.3 修复与防护方案：安全配置清单

必须为生产环境建立严格的安全配置基线：

  1. 敏感信息管理 ：

    • 永远不要 将密码、API密钥、加密密钥等硬编码在代码或配置文件中。
    • 使用环境变量、云服务商密钥管理服务（如AWS KMS, Azure Key Vault）或专门的密钥管理工具（如HashiCorp Vault）来注入敏感信息。
    • 在Spring Boot中，使用 @ConfigurationProperties 或 @Value("${}") 结合环境变量来获取配置。

  2. 异常处理规范化 ：

    • 全局异常处理器（如Spring的 @ControllerAdvice ）应捕获所有异常，并返回统一的、用户友好的错误信息，日志中记录详细堆栈，但HTTP响应中只包含必要的错误代码和消息。
    @ControllerAdvice
public class GlobalExceptionHandler {
    @ExceptionHandler(Exception.class)
    public ResponseEntity<ErrorResponse> handleAllExceptions(Exception ex, WebRequest request) {
        // 记录完整错误日志到后台
        log.error("Internal Server Error: ", ex);
        // 返回给前端的信息
        ErrorResponse error = new ErrorResponse("SERVER_ERROR", "An internal error occurred.");
        return new ResponseEntity<>(error, HttpStatus.INTERNAL_SERVER_ERROR);
    }
}

  3. 管理端点严格管控 ：

    • 生产环境必须 ： management.endpoints.web.exposure.include 只暴露必要的端点，如 health 和 info 。
    • 必须启用访问控制 ： 通过Spring Security对 /actuator/** 路径进行认证和授权，通常只允许内部网络或管理员IP访问。
    • 禁用 health 端点的细节显示： management.endpoint.health.show-details=never

  4. 强化HTTP安全头 ： 可以通过Spring Security或专门的库（如 spring-boot-starter-security ）自动添加安全头，或手动在过滤器/拦截器中设置：

    http.headers()
    .contentSecurityPolicy("default-src 'self'")
    .and()
    .xssProtection()
    .and()
    .frameOptions().deny()
    .and()
    .httpStrictTransportSecurity();

  5. 定期配置审计 ： 将安全配置检查纳入部署清单。可以使用像 Chef InSpec 、 CIS Benchmark 这样的自动化合规工具来检查服务器和中间件配置。

6. 第五类高危漏洞：并发与内存管理缺陷

这类漏洞不像前几种那样容易被外部直接利用，但会导致应用不稳定、性能下降甚至崩溃，同样属于高危问题，尤其在分布式和高并发场景下。

6.1 漏洞原理：资源竞争与生命周期失控

  1. 线程安全漏洞 ：

    • 竞态条件（Race Condition） ： 多个线程同时读写共享资源（如一个静态的 HashMap ），导致数据状态不一致。典型场景是“先检查后执行”，例如单例模式的双重检查锁定实现不当。
    • 死锁（Deadlock） ： 两个或以上线程互相等待对方持有的锁，导致所有相关线程永久阻塞。

  2. 内存泄漏 ：

    • 长生命周期对象持有短生命周期对象的引用 ： 例如，将对象放入一个静态的 Map 中却从未移除，或者在使用线程池时， ThreadLocal 变量未及时清理。
    • 未关闭的资源 ： 数据库连接、文件流、网络连接等未在 finally 块或 try-with-resources 语句中关闭。
    • 监听器未注销 ： 注册了事件监听器但对象销毁时未注销，导致监听器对象无法被回收。

6.2 实战场景：一个缓慢“失血”的服务

我遇到过这样一个案例：一个后台任务服务，使用 Executors.newFixedThreadPool 创建线程池处理消息。每个任务都会创建一个 ThreadLocal<SomeContext> 来保存上下文信息。任务完成后，线程被放回池中重用，但 ThreadLocal 的值没有被清除。由于线程池核心线程永不回收，这些 ThreadLocal 引用及其关联的对象（可能很大）就永远无法被GC释放。运行几周后，服务就因为老年代堆内存占满（ OutOfMemoryError: Java heap space ）而频繁Full GC，最终崩溃。

6.3 修复与防护方案：编写健壮的并发代码

  1. 遵循线程安全最佳实践 ：

    • 优先使用无状态设计 ： 方法尽量不修改共享数据，使用局部变量。
    • 使用线程安全的集合 ： 用 ConcurrentHashMap 代替 HashMap ，用 CopyOnWriteArrayList 代替 ArrayList （读多写少场景）。
    • 同步最小化 ： 只对必要的代码块加锁（ synchronized ），并尽量缩短锁的持有时间。考虑使用更高效的锁机制，如 ReentrantLock 。
    • 避免死锁 ： 按固定的全局顺序获取多个锁。使用 tryLock() 带有超时机制。

  2. 妥善管理线程局部变量 ：

    • 如果使用了 ThreadLocal ， 必须 在任务结束时调用 ThreadLocal.remove() 来清理当前线程的变量副本。这是非常容易忽略的一点。
    private static final ThreadLocal<SimpleDateFormat> dateFormatHolder =
    ThreadLocal.withInitial(() -> new SimpleDateFormat("yyyy-MM-dd"));
public void process() {
    try {
        SimpleDateFormat sdf = dateFormatHolder.get();
        // ... 使用 sdf
    } finally {
        // 关键：务必清理！
        dateFormatHolder.remove();
    }
}

  3. 使用资源池并正确关闭 ：

    • 对于数据库连接池（如HikariCP）、HTTP客户端池等，要正确配置最大、最小连接数，并监控连接泄漏。
    • 一律使用 try-with-resources （Java 7+）来管理任何实现了 AutoCloseable 接口的资源。
    try (Connection conn = dataSource.getConnection();
     PreparedStatement stmt = conn.prepareStatement(sql);
     ResultSet rs = stmt.executeQuery()) {
    // 处理结果集
} // 无需finally块，自动关闭

  4. 内存泄漏排查与监控 ：

    • 启用JVM参数 ： 添加 -XX:+HeapDumpOnOutOfMemoryError -XX:HeapDumpPath=/path/to/dumps ，以便在OOM时自动生成堆转储文件。
    • 使用分析工具 ： 定期使用 jmap , jcmd GC.heap_dump 手动转储堆，或利用JMX连接，通过VisualVM、JProfiler、Eclipse MAT等工具分析堆快照，查找支配树中最大的对象和GC Roots引用链。
    • 监控关键指标 ： 通过JMX或Micrometer等监控JVM堆内存使用情况、GC频率和耗时、线程池活跃度等，建立预警机制。

7. 构建纵深防御体系：从编码到运维

分析了五类具体漏洞后，我们需要一个系统性的方法来应对。安全不是某个阶段的任务，而是贯穿软件生命周期（SDLC）的持续过程。

7.1 安全左移：将安全融入开发流程

  1. 安全需求与设计 ： 在项目初期，就考虑安全架构。明确数据的敏感级别、访问边界、认证授权模型。进行威胁建模，识别潜在的攻击面。
  2. 安全编码规范 ： 制定团队内的Java安全编码规范，并在Code Review中严格执行。规范应包含对本章讨论的所有漏洞的防范要求。
  3. 自动化安全测试（SAST/DAST） ：
    • SAST（静态应用安全测试） ： 在代码提交或CI阶段，使用SonarQube（配合安全插件）、Checkmarx、Fortify等工具扫描源代码，发现潜在的安全漏洞模式。
    • DAST（动态应用安全测试） ： 对运行中的应用进行黑盒测试，使用OWASP ZAP、Burp Suite等工具模拟攻击，发现运行时漏洞。
  4. 依赖扫描（SCA） ： 如前所述，将依赖漏洞扫描作为CI/CD的强制关卡。

7.2 运行时防护与监控

  1. WAF（Web应用防火墙） ： 在应用前端部署WAF，可以拦截常见的SQL注入、XSS、路径遍历等攻击，为应用提供一层缓冲。
  2. RASP（运行时应用自我保护） ： 一种更深入的技术，通过在应用内部（如通过Java Agent）注入安全探针，监控应用的行为（如异常的反射调用、危险的JNDI查找、命令执行等），并在恶意行为发生时进行实时阻断。这可以对未知漏洞和0day攻击提供一定防护。
  3. 全面的日志与审计 ： 记录所有重要的安全事件，如用户登录（成功/失败）、敏感操作（数据导出、权限变更）、访问异常路径等。日志要集中管理（如ELK栈），并设置告警规则（如短时间内大量登录失败）。
  4. 定期渗透测试与红蓝对抗 ： 聘请专业的安全团队或建立内部红队，定期对生产系统进行模拟攻击，以发现自动化工具无法发现的逻辑漏洞和深层隐患。

7.3 事件响应与持续改进

  1. 制定应急预案 ： 针对可能发生的安全事件（如漏洞爆发、入侵告警），制定清晰的应急响应流程（Incident Response Plan），明确责任人、沟通渠道、止损步骤和恢复方案。
  2. 建立漏洞管理闭环 ： 从漏洞披露（关注NVD、CNVD、开源项目安全公告）、内部通告、评估影响、制定修复方案、测试、部署到验证，形成一个完整的闭环流程。
  3. 安全培训与文化 ： 最终，所有技术手段都需要人来执行。定期对开发、测试、运维人员进行安全意识和技术培训，让安全成为每个人的责任和习惯。

安全是一个动态的过程，没有一劳永逸的银弹。作为开发者，我们能做的是保持警惕，理解漏洞产生的根本原因，在设计和编码阶段就规避风险，并利用工具和流程构建多层次的防御。从每次漏洞分析和修复中学习，不断加固你的应用，这才是应对层出不穷的安全挑战最有效的方法。

Logo
亚马逊云科技技术品牌专区

更多推荐

2026年量化工具选择，要跟着能力基础走

读者应理解，选择工具前要先判断自己的能力基础和当前任务。工具应该帮助自己补上当前最关键的缺口，而不是替代学习顺序本身。

avatar 亚马逊云科技技术品牌专区

近期零基础学量化，先按基础差异拆学习顺序

读者应明白，拆解学习顺序时要先看自己的基础缺口，再决定哪一段需要放慢。不同流程阶段都有不同检查任务，学习路线要能反映这些差异。

avatar 亚马逊云科技技术品牌专区

加州理工 CS367 C 语言系统编程笔记（一）

C语言是一种强大且广泛使用的编程语言，尤其在系统编程领域。本节课我们将学习C语言的基础语法，包括如何编写“Hello, World!”程序、声明变量以及使用基本数据类型。我们将通过实际的代码示例来加深理解。本节课中我们一起学习了C语言的基础语法，包括如何编写和运行一个简单的C程序、声明变量以及使用基本数据类型。我们还介绍了如何使用Shell环境来编译和运行程序。通过对比Java，你可以看到C语言在

avatar 亚马逊云科技技术品牌专区