Java读取Properties文件的几种方法

golang学习网今天将给大家带来《Java读取.properties文件方法详解》，感兴趣的朋友请继续看下去吧！以下内容将会涉及到等等知识点，如果你是正在学习文章或者已经是大佬级别了，都非常欢迎也希望大家都能给我建议评论哈~希望能帮助到大家！

在Java中读取.properties配置文件，主要通过java.util.Properties类实现，常见方式有两种：1. 从文件系统路径读取，适用于外部可修改的配置；2. 从类路径读取，更推荐用于应用内部配置。两者均通过InputStream加载配置，使用getProperty()获取键值。.properties文件因其简单直观，适用于扁平化、少量配置的场景，而JSON/YAML更适合复杂结构或数据交换。处理配置文件时常见陷阱包括路径问题、硬编码默认值、缺乏错误处理、敏感信息泄露等，最佳实践包括优先从类路径加载、使用try-with-resources、健壮的错误处理、外部化配置、敏感信息加密管理、统一配置入口及提供默认值。在Spring Boot中，可通过@Value、@ConfigurationProperties实现类型安全的配置注入，支持多环境配置及配置中心，极大提升了配置管理的便捷性与灵活性。

在Java中读取.properties配置文件，核心就是利用java.util.Properties这个类。它提供了一套非常直观的API来加载、存储和操作键值对数据，这些数据通常以key=value的形式存储在文本文件中。无论是从文件系统还是从类路径加载，它的基本原理都大同小异：先获取一个输入流，然后交给Properties对象去解析。

解决方案

读取.properties文件主要有两种常见方式，取决于你的配置文件是放在文件系统的某个绝对或相对路径，还是作为资源文件打包在你的JAR包里（即在classpath下）。

1. 从文件系统路径读取： 这种方式适用于配置文件独立于应用程序包，可能需要外部修改的情况。你需要提供文件的完整路径。

import java.io.FileInputStream;
import java.io.IOException;
import java.util.Properties;

public class ConfigReaderFromFile {

    public static void main(String[] args) {
        Properties prop = new Properties();
        String configFilePath = "config.properties"; // 假设config.properties在项目根目录或指定路径

        // 尝试从文件系统加载
        try (FileInputStream fis = new FileInputStream(configFilePath)) {
            prop.load(fis); // 加载属性文件
            System.out.println("数据库URL: " + prop.getProperty("db.url"));
            System.out.println("用户名: " + prop.getProperty("db.username"));
            System.out.println("密码: " + prop.getProperty("db.password"));

            // 尝试获取一个不存在的属性，并提供默认值
            System.out.println("默认端口 (如果未设置): " + prop.getProperty("server.port", "8080"));

        } catch (IOException ex) {
            System.err.println("读取配置文件出错: " + ex.getMessage());
            // 实际应用中，这里可能需要更复杂的错误处理，比如日志记录或抛出自定义异常
        }
    }
}

创建一个名为 config.properties 的文件在项目根目录（或 configFilePath 指定的路径）：

db.url=jdbc:mysql://localhost:3306/mydb
db.username=root
db.password=mypass

2. 从类路径（Classpath）读取： 这是更推荐的方式，特别是当配置文件是应用程序的一部分，并且会随着应用程序一起部署时。它避免了硬编码文件路径的问题，让应用程序更具可移植性。

import java.io.IOException;
import java.io.InputStream;
import java.util.Properties;

public class ConfigReaderFromClasspath {

    public static void main(String[] args) {
        Properties prop = new Properties();
        String configFileName = "application.properties"; // 假设文件在resources目录下

        // 尝试从类路径加载
        // 使用当前线程的ClassLoader或当前类的ClassLoader
        try (InputStream input = ConfigReaderFromClasspath.class.getClassLoader().getResourceAsStream(configFileName)) {
            if (input == null) {
                System.err.println("对不起，找不到 '" + configFileName + "' 文件。请确保它在classpath中。");
                return;
            }
            prop.load(input);

            System.out.println("应用名称: " + prop.getProperty("app.name"));
            System.out.println("版本: " + prop.getProperty("app.version"));
            System.out.println("作者: " + prop.getProperty("app.author", "未知")); // 带默认值

        } catch (IOException ex) {
            System.err.println("读取配置文件出错: " + ex.getMessage());
        }
    }
}

在你的Maven或Gradle项目的 src/main/resources 目录下创建 application.properties 文件：

app.name=MyAwesomeApp
app.version=1.0.0

可以看到，无论哪种方式，核心都是Properties类的load()方法，它接收一个InputStream。关键在于如何获取这个InputStream。getProperty(key)用于获取指定键的值，而getProperty(key, defaultValue)则允许你在键不存在时提供一个默认值，这在处理可选配置项时非常有用。

为什么我们还需要.properties文件？它和YAML/JSON有何不同？

嗯，这问题问得好。在JSON和YAML大行其道的今天，很多人可能会觉得.properties文件有点“老派”了。但说实话，它依然有其存在的价值，尤其是在一些特定的场景下。

我个人觉得，.properties文件的最大优点就是简单直接。它就是纯粹的键值对，一眼就能看明白，没有复杂的嵌套结构，也没有各种括号、缩进的语法规则。对于那种扁平化的、少量配置项的场景，比如数据库连接字符串、一些服务端口号、应用名称版本号之类的，它简直是完美。维护起来也极其方便，随便一个文本编辑器就能搞定，甚至不需要特定的插件来高亮语法。对于一些老项目，或者只需要少量配置的工具类应用，它仍然是首选，因为它“轻”。

那和JSON/YAML比起来呢？这就像是拿一辆小轿车和一辆SUV比较。

JSON (JavaScript Object Notation)：

• 优点： 结构化能力极强，可以表示复杂的嵌套对象和数组。它是一种数据交换格式，所以非常适合API响应、日志记录以及需要复杂数据结构的配置。解析速度快，几乎所有编程语言都有成熟的库支持。
• 缺点： 语法相对.properties更严格，多一个逗号或少一个括号都可能导致解析失败。对于人眼来说，阅读起来可能不如.properties直观，尤其是层级深的时候，满眼的括号和引号有点让人头疼。

YAML (YAML Ain't Markup Language)：

• 优点： 强调“人类可读性”，通过缩进来表示层级关系，语法比JSON更简洁（少了大量的括号和引号）。同样能表示复杂的嵌套结构，而且非常适合配置文件的场景，很多现代框架（比如Spring Boot、Kubernetes）都倾向于使用YAML作为默认配置文件格式。
• 缺点： 缩进敏感，一个空格的差异都可能导致解析错误，这在团队协作或手动编辑时容易犯错。虽然比JSON更易读，但对于初学者来说，其结构化方式可能需要一点时间适应。

所以，我的看法是：

• 如果你需要一个扁平、简单、快速上手的配置文件，并且配置项不多，.properties依然是你的好朋友。
• 如果你需要复杂、嵌套、结构化的配置，或者需要与其他系统进行数据交换，JSON是更合适的选择。
• 如果你希望配置既能表示复杂结构，又兼顾人类可读性，并且愿意接受缩进敏感的规则，那么YAML会是现代项目的优选。

选择哪种，很多时候真的是看项目需求、团队习惯以及个人偏好。我个人在一些简单的Java小工具里，还是会习惯性地用.properties，因为它够用，而且真的省心。

处理配置文件时常见的陷阱与最佳实践是什么？

说起配置文件，我可没少踩坑，也总结了一些血泪教训。这东西看起来简单，但真要用好，还是得讲究点策略。

常见的陷阱：

1. 文件路径问题： 这是最最常见的。比如，我一开始总是习惯用new FileInputStream("config.properties")，然后发现程序在IDE里跑得好好的，打包成JAR一运行就报错“文件找不到”。原因就是FileInputStream默认是相对当前工作目录，而打包后的JAR运行环境可能不是你期望的目录。正确的做法是，如果文件是应用的一部分，应该用ClassLoader.getResourceAsStream()从类路径加载；如果文件是外部的，需要明确指定绝对路径或者通过命令行参数传入路径。
2. 硬编码默认值： 有时候图省事，直接在代码里写死一些配置值。结果呢？环境一变，比如从开发环境到测试环境，或者数据库地址变了，就得改代码、重新编译、重新部署。这简直是自找麻烦。
3. 缺乏错误处理： 配置文件找不到？属性键不存在？load()方法抛IOException？getProperty()返回null？很多时候，我们写代码时会忽略这些异常情况。结果就是，一旦配置文件有点小问题，程序直接崩溃，用户体验极差，排查起来也费劲。
4. 修改运行时配置： 有些人会尝试在程序运行期间修改.properties文件，然后期望程序立即生效。这通常是行不通的，因为Properties对象加载后，它只是内存中的一个副本。如果你真的想实现动态配置，那需要更复杂的机制，比如监听文件变化，或者使用专门的配置中心服务。直接改文件并指望立即生效，往往是徒劳的。
5. 敏感信息泄露： 数据库密码、API密钥这些敏感信息直接明文写在.properties文件里，然后把文件提交到版本控制系统？这是个巨大的安全隐患！一旦仓库泄露，后果不堪设想。

最佳实践：

1. 优先从Classpath加载： 对于应用程序内部的配置，始终优先使用ClassLoader.getResourceAsStream()。这能保证你的应用无论部署到哪里，只要配置文件在classpath中，就能被找到。
2. 使用try-with-resources： 在处理InputStream时，务必使用try-with-resources语句。这能确保流在不再需要时自动关闭，避免资源泄露。
3. 健壮的错误处理：
   • load()方法要捕获IOException，并给出有意义的错误提示或日志。
   • getProperty()方法获取值时，要考虑返回null的情况。可以使用getProperty(key, defaultValue)提供默认值，或者在获取后进行null检查。
   • 对于关键配置项，如果缺失，甚至可以直接抛出自定义的配置异常，强制程序中断，避免在后续逻辑中出现更隐蔽的错误。
4. 外部化配置： 对于不同环境（开发、测试、生产）需要不同配置的情况，将配置文件放在应用程序外部，通过JVM参数、环境变量或特定目录加载。这样，同一套代码部署到不同环境，只需要修改配置文件即可。
5. 敏感信息加密或外部管理：
   • 对于数据库密码、API密钥等敏感信息，绝对不能明文存储。可以考虑对这些值进行加密，在程序中解密。
   • 更推荐的做法是使用专门的秘密管理服务，比如HashiCorp Vault、AWS Secrets Manager，或者利用云服务商提供的密钥管理服务。
   • 在开发环境中，可以通过环境变量注入这些敏感值，而不是写入文件。
6. 单一配置入口： 避免在代码库的各个角落散布配置读取逻辑。最好有一个专门的ConfigManager或AppConfig类来统一管理所有配置的加载和访问。这样，当配置逻辑需要修改时，只需要在一个地方进行维护。
7. 提供默认值： 对于非强制性的配置项，始终提供合理的默认值。这能让程序在某些配置项缺失时也能正常运行，提高健壮性。

总之，处理配置文件，就是要把“配置”和“代码”解耦，让程序更灵活、更健壮、更安全。

如何在Spring Boot等框架中更优雅地管理配置？

当我们从原生Java跳到像Spring Boot这样的现代框架时，配置管理的体验简直是天壤之别。Spring Boot在配置方面做了大量开箱即用的工作，把.properties（以及YAML）的使用提升到了一个全新的高度，让开发者能以更优雅、更类型安全的方式来管理配置。

在Spring Boot中，你几乎不需要手动去写new Properties().load()那些代码了，框架已经帮你把这事儿给办了。它默认会加载src/main/resources目录下的application.properties或application.yml文件。

1. @Value注解： 这是最简单直接的方式，用于注入单个配置属性。

import org.springframework.beans.factory.annotation.Value;
import org.springframework.stereotype.Component;

@Component
public class MyService {

    @Value("${app.name}") // 从application.properties中读取app.name
    private String appName;

    @Value("${server.port:8080}") // 如果server.port不存在，则使用默认值8080
    private int serverPort;

    public void printConfig() {
        System.out.println("Spring Boot App Name: " + appName);
        System.out.println("Spring Boot Server Port: " + serverPort);
    }
}

application.properties:

app.name=SpringDemoApp

这种方式非常方便，但如果配置项很多，或者需要注入到不同的类中，就会显得有点分散。

2. @ConfigurationProperties注解： 这是我个人最喜欢的方式，它提供了一种类型安全的配置管理方案。你可以把相关的配置项映射到一个Java对象上，让配置像普通Java对象一样被管理。

import org.springframework.boot.context.properties.ConfigurationProperties;
import org.springframework.stereotype.Component;

@Component
@ConfigurationProperties(prefix = "db") // 映射所有以"db."开头的属性
public class DatabaseProperties {

    private String url;
    private String username;
    private String password;
    private int maxPoolSize = 10; // 可以设置默认值

    // Getters and Setters (Spring Boot需要它们来注入属性)
    public String getUrl() { return url; }
    public void setUrl(String url) { this.url = url; }
    public String getUsername() { return username; }
    public void setUsername(String username) { this.username = username; }
    public String getPassword() { return password; }
    public void setPassword(String password) { this.password = password; }
    public int getMaxPoolSize() { return maxPoolSize; }
    public void setMaxPoolSize(int maxPoolSize) { this.maxPoolSize = maxPoolSize; }

    @Override
    public String toString() {
        return "DatabaseProperties{" +
               "url='" + url + '\'' +
               ", username='" + username + '\'' +
               ", password='[PROTECTED]'" + // 避免打印敏感信息
               ", maxPoolSize=" + maxPoolSize +
               '}';
    }
}

application.properties:

db.url=jdbc:mysql://localhost:3306/spring_db
db.username=springuser
db.password=springpass
db.maxPoolSize=20

然后你就可以在其他组件中直接注入DatabaseProperties对象来使用配置了：

import org.springframework.beans.factory.annotation.Autowired;
import org.springframework.stereotype.Service;

@Service
public class DataService {

    private final DatabaseProperties dbProps;

    @Autowired
    public DataService(DatabaseProperties dbProps) {
        this.dbProps = dbProps;
    }

    public void showDbConfig() {
        System.out.println("DB Config: " + dbProps);
    }
}

这种方式的优势在于：

• 类型安全： 编译时就能发现类型不匹配的问题。
• 集中管理： 相关的配置属性都集中在一个类中。
• IDE支持： IDE通常能提供自动补全和验证。
• 外部化： Spring Boot的外部化配置能力，允许你通过命令行参数、环境变量、Profile特定文件等多种方式覆盖这些属性。

3. 多环境配置： Spring Boot对多环境配置的支持简直是神来之笔。你可以在src/main/resources下创建多个配置文件，例如：

• application.properties (通用配置)
• application-dev.properties (开发环境特定配置)
• application-test.properties (测试环境特定配置)
• application-prod.properties (生产环境特定配置)

然后通过spring.profiles.active属性来激活特定的环境配置，例如在命令行运行： java -jar your-app.jar --spring.profiles.active=dev 或者在application.properties中设置： spring.profiles.active=dev 这样，Spring Boot会自动加载通用配置，并用特定环境的配置覆盖同名属性。

4. 配置中心： 对于微服务架构或更复杂的分布式系统，Spring Cloud Config Server是终极解决方案。它提供了一个集中式的外部配置管理服务，应用程序可以从Config Server动态获取配置。这意味着你可以在不重启服务的情况下更新配置，这对于生产环境的热更新至关重要。

总而言之，Spring Boot极大地简化了Java应用中的配置管理。从简单的@Value到类型安全的@ConfigurationProperties，再到强大的多环境支持和配置中心，它提供了一套非常完整且优雅的配置解决方案，让开发者可以专注于业务逻辑，而不是繁琐的配置细节。

以上就是《Java读取Properties文件的几种方法》的详细内容，更多关于的资料请关注golang学习网公众号！