这篇文章是在完成软件构造实验的过程中，记录的一些花了一段时间才找到原因的问题的整理。前面几个是比较简单的问题，但是确实困扰了刚接触Java的我不少时间，后面几个是在实验功能已经实现，测试的时候暴露出来的问题。
- Java字符串的比较
一个字符串是一个String类的实例，比较两个字符串是否相等需要使用equals方法。==可以用来比较基本数据类型是否相等，而用在对象上只是比较两个对象的内存地址是否相等。
现在看起来，这是一个相当简单的错误，但是当时对对象的理解不够透彻，对Java将数据类型分为基本数据类型和对象还不是很理解，所以造成了错误。
- HashSet的contains方法使用hashcode进行比较
HashSet底层是一个HashMap，HashMap通过散列表排列数据，散列值是数据的hashcode。所以设计一个类之后，需要重写equals方法和hashCode方法，如果只重写了equals方法，将数据加入HashSet中，再使用contains方法查询集合中是否存在该元素时会出错。
- 列表元素的删除
ArrayList是List下最常用的类，在ArrayList中删除某个元素有几个需要注意的地方。
for循环遍历时删除元素：在for循环中找到要删除的元素，假设为第i个，删除后，原来第i+1个元素变成第i个，如果直接进入下一轮循环，则跳过了原来的第i+1个元素，可能会出现错误。而且由于在循环中删除元素，所以判断循环结束的条件不能是提前读取的列表的大小，否则会造成访问越界。
foreach循环遍历时删除元素：很容易抛出java.util.ConcurrentModificationException异常，所以不推荐这种方式，虽然有些情况下可以正常删除，可以参考这篇博客。
- 安全拷贝耗时问题
在开始设计程序的时候，比较注重程序的安全性，在类对外提供的观察类内部内容的方法中都使用了安全拷贝，这本来也没错。但是等到测试程序性能时，打开VisualVM查看最耗时的方法，排在前面的都是几个类的clone方法。当然这并不意味着不要使用安全拷贝，而要根据程序的逻辑，减少安全拷贝方法的使用。例如在实验中，需要根据一个顶点的label查找ConcreteGraph中的顶点，最初设计时是在ConcreteGraph类外面获取图上的所有顶点，然后找到具有该label的顶点，这样就必然要调用安全拷贝方法，造成耗时。改进措施是在ConcreteGraph中添加一个根据label找顶点的方法，ConcreteGraph直接拥有顶点集，不需要安全拷贝，这样就避免了安全拷贝的耗时。另外还要注意在提供安全拷贝方法的类中避免使用安全拷贝方法，安全拷贝方法应该是提供给外部类使用，类里面使用会造成不必要的耗时。
- 使用equals方法耗时问题
在集合或者列表中使用equals方法比较找到某一个元素，时间复杂度是O(n)，随着集合元素的增加，比较会越来越慢。使用哈希表会是个比较好的选择，例如在HashSet中查找一个元素时间复杂度为O(1)。当数据量非常大时，两者的差距非常明显。
在实验测试程序的性能的过程中，发现的第一个问题是上面提到的安全拷贝问题，做了改进以后，clone方法不再是最耗时的方法，取而代之的是equals方法，定位到具体代码，该处程序是将一条边添加到ConcreteGraph中，添加之前需要判断边集合中是否存在具有相同label的边，若有，则需要自动修改label。这样就需要遍历这个边的集合，并使用equals方法进行比较，而且随着加入的边越来越多，比较的过程会越来越慢。于是想到了使用一个HashSet专门存放边的label，这样，添加边时，只需要在这个集合中查找，时间复杂度为O(1)，不会随着加入的边越来越多造成程序运行越来越慢，做了这个改进以后，程序读取一个有30多万条边的文件并建图的完成时间从一个小时完成不了变成了一分多钟。后面又做了一些修改，例如加了一个HashMap存放顶点的label和顶点的对应关系，这样，根据label查找顶点的时间复杂度也降为O(1)，也就是做了空间换时间的改进，最后只需二三十秒便可完成。
