Druid连接池，相同ip和port的数据源获取conn的小坑

前提背景：项目前端可选择不同数据库下不同数据源的某张表来查询数据（具体业务暂且不提，知道是前端查询数据库数据即可），所以后端代码中使用到了conn连接池的技术，提高查询效率。

DruidUtil存放conn是map，key为数据源实体的id，value就是conn。
这是数据源实体，注意id是什么：

public class Datasource extends DataBase implements Serializable {
    private String id;
    private String ipAddress;
    private String port;
    private String userName;
    private String passwd;
    private String type;
    private String name;
    private String connectionMode;
    
    public Datasource(String ipAddress,String port,String username,String passwd,String type,String name,String connectionMode ){
        this.id=ipAddress+":"+port;
        this.ipAddress=ipAddress;
        this.port=port;
        this.userName=username;
        this.passwd=passwd;
        this.type=type;
        this.name=name;
        this.setConnectionMode(connectionMode);
    }
}

在开发环境中，连接池使用的没什么问题，直到测试环境，碰到了一个问题：
选择了mysql数据库下的mysql-A数据源中的table-A表，查询数据之后，再选择mysql数据库下的mysql-B数据源中的table-B表，此时报错：mysql-A.table-B 不存在

疑问：表名确实是第二次选择的数据源（mysql-B）下的表名（table-B），但是为什么前面的库名（schema）会是上一个数据源（mysql-A）的？

查看项目的运行日志信息：发现mysql-A和mysql-B数据源的所有信息都一样，只有名字不一样。在联想到获取druid中的conn，是通过id获取的，而id是由ip+port构成的，那么是不是可以认为：第二次选择的mysql-B数据源，获取的conn实际上是第一次存放的mysql-A的数据源，DruidUtil并没有为mysql-B数据源新建conn？
一番测试后发现确实是因为id的原因导致的这个问题。至于测试过程其实也没什么好贴出来的，无非就是把数据源实体的id更换一下，查看ip和port数据源相同时获取的conn是否一样，修改id保证唯一即可。

修改后的id为 this.id=ipAddress+":"+port+":"+name;

小结：
①项目中的运行日志信息真的非常重要，对于问题的排查很有帮助。如果不是发现数据源除了名字不同，其他都相同的信息，这个问题还真不好找。
②数据源在同一台服务器并且端口相同的情况也是有