参考资料：https://www.mchange.com/projects/c3p0/#configuration_properties，由于笔者英文水平有限，下面均采用的机器翻译，如有问题还请谅解。
以下配置属性会影响整个 c3p0 库的行为。它们可以设置为系统属性、c3p0.properties 文件或 HOCON（类型安全配置）文件。
通常，c3p0 的配置信息放在应用程序 CLASSPATH 顶层的 c3p0-config.xml 或 c3p0.properties 文件中。但是，如果您希望将配置信息放在其他位置，则可以将 c3p0 配置信息（仅以 XML 文件格式！）放置在应用程序可见的文件系统中所需的任何位置。只需将以下属性设置为 XML 配置文件的完整绝对路径：
com.mchange.v2.c3p0.cfg.xml
如果将此属性设置为以 “classloader:” 开头的值，c3p0 将搜索 XML 配置文件作为类加载器资源，即在类路径下指定的任何位置，包括 jar 文件 META-INF 目录。
出于对 XML 引用自由解析的安全问题，c3p0 现在默认解析 XML 文件非常严格。除此之外，它不再扩展 XML 配置文件中的实体引用。实体引用可能会被静默忽略！它也不再支持 xml 包含，并且如果 JVM 的底层 XML 库支持内联文档类型定义，则会尝试禁用任何内联文档类型定义的使用。在极少数情况下，如果配置有意依赖于实体引用扩展、DTD、XML 包含或其他危险功能，您可以重新打开宽松解析，恢复 c3p0 的传统行为。在还原旧的宽松行为之前，请确保您了解安全问题，并信任您对 XML 配置文件的控制和完整性。然后，如果您愿意，可以将以下属性设置为 true：
com.mchange.v2.c3p0.cfg.xml.usePermissiveParser
这将恢复 c3p0 在 c3p0-0.9.5.3 之前的版本中默认使用的 XML 配置文件的传统、自由解析。（从版本 0.9.5.4 开始，com.mchange.v2.c3p0.cfg.xml.usePermissiveParser 替换了 0.9.5.3 中引入的现已弃用的 com.mchange.v2.c3p0.cfg.xml.expandEntityReferences，因为现在限制的不仅仅是实体引用扩展。
以下属性会影响 c3p0 的日志记录行为。有关特定信息，请参阅上面的配置日志记录。
com.mchange.v2.log.MLog com.mchange.v2.log.jdk14logging.suppressStackWalk com.mchange.v2.log.NameTransformer com.mchange.v2.log.FallbackMLog.DEFAULT_CUTOFF_LEVEL
以下属性会影响 c3p0 的 JMX 管理接口。有关详细信息，请参阅上面的通过 JMX 配置和管理 c3p0。
com.mchange.v2.c3p0.management.ExcludeIdentityToken com.mchange.v2.c3p0.management.RegistryName com.mchange.v2.c3p0.management.ManagementCoordinator
是漂亮还是正确更好？从C3P0-0.9.1开始，C3P0有点勉强地选择了正确性。
事情是这样的。每个 C3P0 数据源都被分配了一个唯一的 “身份令牌”，该令牌用于确保同 —— PooledDataSource 的多个 JNDI 查找始终返回相同的实例，即使 JNDI 名称服务器存储了序列化或引用的实例。以前，C3P0 很高兴生成的 ID 在单个VM中是唯一的 (在 C3P0-0.9.1 之前，它甚至没有完全正确地做到这一点)。
但在理论上，一个虚拟机可能会查找由两个不同的虚拟机生成的两个不同的数据源，这两个数据源不太可能巧合地具有相同的 “身份令牌”，从而导致错误，因为这两个数据源中的一个偷偷地替代了另一个数据源。虽然这个假设的问题在实践中从未被报告过，但 C3P0 通过在其身份令牌中添加一个 VMID 来解决该问题。这使得它们又长又丑，但却是正确的。
如果您不喜欢冗长而丑陋的 VMID，可以设置自己的 VMID，也可以完全使用以下属性将此解决方案关闭为假设的非问题：
com.mchange.v2.c3p0.VMID
将其设置为 NONE 以关闭 VMID，将其设置为 AUTO 以让 c3p0 生成 VMID，或提供任何其他字符串来设置将直接使用的 VMID。默认值为自动。
在 JDBC 4+ isValid(...) 测试将由 c3p0 内置的 DefaultConnectionTester 使用的情况下（见下文），默认情况下，测试永远不会超时。如果测试超时并失败，请设置以下键
com.mchange.v2.c3p0.impl.DefaultConnectionTester.isValidTimeout
到所需的超时，以秒为单位。
c3p0 的内置 DefaultConnectionTester 在您提供了 preferredTestQuery 或 automaticTestTable 参数时，会做正确而明显的事情。但是，当它没有用户确定的查询来测试连接时，c3p0应该做什么就不太清楚了。在 JDBC 3 API 中，没有直接、可靠的方法来测试 JDBC 连接。c3p0 的 DefaultConnectionTester 采用了非常保守的技术，使用 Connection 来查询 DatabaseMetaData，因为这表示对数据库的实时查询，可以在不了解数据库模式的情况下执行。不幸的是，这种技术通常非常非常慢。
幸运的是，从版本 0.9.5 开始，c3p0 支持使用 Connection.isValid() 方法对 JDBC 4 API 进行测试。这是由 JDBC 驱动程序提供程序指定和实现的快速、可靠的测试。
尽管很少需要这样做，但用户现在可以准确指定如果未通过以下属性设置首选测试查询或自动测试表，则 DefaultConnectionTester 的行为方式：
com.mchange.v2.c3p0.impl.DefaultConnectionTester.querylessTestRunner
性的可能值包括：
METADATA_TABLESEARCH 这是 c3p0 非常慢但非常可靠的传统默认连接测试。它甚至可以与非常旧的JDBC驱动程序一起使用。
IS_VALID 这使用新的 JDBC 4 API 来执行驱动程序定义的连接测试。但是，如果将 AbstractMethodError 与旧的 JDBC 3 驱动程序一起使用，则会引发它。
SWITCH 这首先尝试新的 JDBC 4 连接测试（如 IS_VALID），但捕获任何 AbstractMethodError 并在必要时回退到 METADATA_TABLESEARCH。
THREAD_LOCAL 这将检查新的 Connection.isValid() 方法是否可用于它测试的任何 Connection 实现，并存储 ThreadLocal WeakHashMap 以跟踪哪些 Connection 实现支持该方法。然后，它会查阅地图并根据需要运行快速 IS_VALID 测试或通用 METADATA_TABLESEARCH 测试。
您还可以提供 DefaultConnectionTester.QuerylessTestRunner 接口实现的完全限定类名，并定义您自己的行为，无论您想做什么。你的类应该是公共的，有一个公共的无参数构造函数，并且是线程安全和可共享的。（c3p0 池通常只使用一个 ConnectionTester 来测试其所有连接，通常是同时进行的。有关示例，请参阅 c3p0 源代码中的内置实现。
默认值为 SWITCH，它几乎总是没问题。
真的，您几乎不应该费心设置此属性。如果您使用的是旧的 JDBC 驱动程序，并且希望消除尝试 isValid() 方法然后捕获 AbstractMethodError 的小开销，则可以将其值设置为 METADATA_TABLESEARCH。但是，当一种更快的方法是设置首选TestQuery并完全避免无查询测试时，为什么要打扰呢？如果你想做一些完全不同的事情，你可以实现你自己的 DefaultConnectionTester.QuerylessTestRunner。或者你可以直接实现 ConnectionTester，并设置参数 connectionTesterClassName。
c3p0-0.9.1 包括异步连接获取的新实现，在数据库获取尝试（无论出于何种原因）偶尔失败的情况下，它应该可以提高 c3p0 的性能和资源利用率。新的实现应该比“传统”的连接获取策略要好得多，但在 c3p0-0.9.1 开发周期中添加得太晚，默认情况下无法进行全面测试和启用。鼓励用户尝试新的实现，因为它更好，并帮助解决任何意想不到的问题。
有关新实现及其旨在克服的资源瓶颈的完整描述，请参阅 c3p0-0.9.1-pre11 的 CHANGELOG 条目。
从 c3p0-0.9.2 开始，此功能默认启用。若要恢复到传统的连接获取行为，请将以下参数设置为 false。
com.mchange.v2.resourcepool.experimental.useScatteredAcquireTask
