Question

java里的List<T>接口里的subList方法，API没看懂

第一点，什么是视图？这个词是翻译者发明出来的吗？是不是说子列表和源列表共用一个引用数组，只是子列表的使用权限限制在了截取指定的那两个索引之间？第二点，非结构性更改，clear是结构性更改吗？如api上写的，调用subList(a,b).clear()能清除a到b之前的元素，实际上它也是把子列表清空了，这样用是完全可以的，但为什么对原列表clear操作就会报错？第三点，其实List的实现方式我也不懂，是不是就是我第一点说的，内部维护了一个引用数组，分别指向存储的对象？删除元素就是删除引用，然后等gc回收？啊啊啊，今天真的是被集合里的一些东西搞晕了，知道怎么用，但不知道它到底怎么实现的，不痛快啊，泛型的类型擦除也头疼，他俩凑一块更头疼了....

Answer 1

1，并不是发明出来的，原文就是view，就是视图的意思。
视图的概念借用了数据库的view概念。sablist返回的list和原来的list，后面的数据是同一份，所以对任何item本身的修改，会反映到另一个list。
2，因为sublist知道使用了哪个fullList，当然能够正确处理clear；反过来却不然，所以，对fullList的clear，会造成未定义的结果。

3，如果是arrayList，是你说的那样，remove的话，会把后面的数据向前串一个，然后等着回收呗；如果是link list，就是链表结构了。

追问

13懂了，2还是有点2，看来还是我太二了。。是不是说sublist的一系列操作都会得到很明确的结果，而改变fulllist结构带来的后果对于sublist却是未知的，后者的这种改变会完全破坏sublist的意义？

追答

你子列表不是调用subList方法取来的么，这时候，你是能知道full列表的情况的，所以实现的时候，比如你remove一个元素，告诉fullList也remove就行了；
但是反过来就不行了，fullList哪知道有几个子列表在盯着自己啊，不知道，所以一删除就完蛋了，子列表不知道这个情况啊，不知道实际上自己的长度少了一个。。。
所以，只能你自己保证，调用subList操作的期间，不能动fullList了。

追问

大概就这样了吧，你是第一个回答的，采纳了

Answer 2

视图这个概念，怎么讲呢，它是对原始数据的一种映射，至于怎么映射，看具体实现。
比如说[1, 2, 3]这个数组，按某种映射成['a', 'b', 'c']，那么后者也是前者的视图。

具体到你这个问题，你的说法基本正确，反正对视图的修改会映射回原始数据，对原始数据的修改也会反映在视图上，你知道这一点就行了。

第二点，clear()当然是结构性修改。对原列表clear()会报错？不是很懂你意思，上代码。

第三点，List没有实现，它只是一个接口。具体的实现如ArrayList、LinkedList等的结构都是不一样的。删除元素就是删除引用，这个没有错。

追问

可以了可以了，辛苦，只是你晚了一步😁