不过我认为你选错方向了……如果该方法返回一个TestA对象列表，那么将它们强制转换到TestB确实是不安全的。

基本上，您是在要求编译器允许您在不支持TestA类型的TestB上执行操作。

当您强制转换对象引用时，您只是强制转换引用的类型，而不是对象的类型。强制转换不会改变对象的实际类型。

Java没有转换对象类型的隐式规则。(与原语)

相反，您需要提供如何将一种类型转换为另一种类型并手动调用它。

public class TestA {}
public class TestB extends TestA{ 
    TestB(TestA testA) {
        // build a TestB from a TestA
    }
}

List<TestA> result = .... 
List<TestB> data = new List<TestB>();
for(TestA testA : result) {
   data.add(new TestB(testA));
}

这比在有直接支持的语言中更冗长，但它是可行的，您不需要经常这样做。

在Java 8中，实际上可以做到

List<TestB> variable = collectionOfListA
    .stream()
    .map(e -> (TestB) e)
    .collect(Collectors.toList());

由于这是一个被广泛引用的问题，目前的答案主要解释了为什么它不起作用(或者提出了我永远不希望在生产代码中看到的俗套、危险的解决方案)，我认为应该添加另一个答案，展示陷阱和可能的解决方案。

在其他回答中已经指出了一般情况下这不能工作的原因:转换是否实际有效取决于原始列表中包含的对象的类型。当列表中有对象的类型不是TestB类型，而是TestA的不同子类时，则强制转换无效。

当然，类型转换可能是有效的。有时，您拥有编译器无法使用的类型信息。在这些情况下，可以强制转换列表，但通常不建议这样做:

一个人可以……

．.． 转换整个列表或 ．.． 强制转换列表中的所有元素

The implications of the first approach (which corresponds to the currently accepted answer) are subtle. It might seem to work properly at the first glance. But if there are wrong types in the input list, then a ClassCastException will be thrown, maybe at a completely different location in the code, and it may be hard to debug this and to find out where the wrong element slipped into the list. The worst problem is that someone might even add the invalid elements after the list has been casted, making debugging even more difficult.

调试这些虚假classcastexception的问题可以通过Collections#checkedCollection系列方法缓解。

基于类型筛选列表

从List<Supertype>转换到List<Subtype>的一种更类型安全的方法是实际筛选列表，并创建一个只包含具有特定类型的元素的新列表。这种方法的实现有一定程度的自由度(例如，关于空项的处理)，但一种可能的实现可能是这样的:

/**
 * Filter the given list, and create a new list that only contains
 * the elements that are (subtypes) of the class c
 * 
 * @param listA The input list
 * @param c The class to filter for
 * @return The filtered list
 */
private static <T> List<T> filter(List<?> listA, Class<T> c)
{
    List<T> listB = new ArrayList<T>();
    for (Object a : listA)
    {
        if (c.isInstance(a))
        {
            listB.add(c.cast(a));
        }
    }
    return listB;
}

这个方法可以用来过滤任意列表(不仅仅是关于类型参数的给定子类型-超类型关系)，如下例所示:

// A list of type "List<Number>" that actually 
// contains Integer, Double and Float values
List<Number> mixedNumbers = 
    new ArrayList<Number>(Arrays.asList(12, 3.4, 5.6f, 78));

// Filter the list, and create a list that contains
// only the Integer values:
List<Integer> integers = filter(mixedNumbers, Integer.class);

System.out.println(integers); // Prints [12, 78]

泛型的强制转换是不可能的，但是如果你以另一种方式定义列表，则可以将TestB存储在其中:

List<? extends TestA> myList = new ArrayList<TestA>();

在使用列表中的对象时，仍然需要进行类型检查。

2022年回答

将一组超类型的List转换为一组子类型的List是没有意义的，任何人都不应该尝试或甚至考虑这样做。如果你认为你的代码需要这样做，你需要重写你的代码，使它不需要这样做。

对于这个问题，大多数访问者可能想要做相反的事情，这实际上是有道理的:

将子类型列表转换为超类型列表。

我发现的最好的方法是:

List<TestA> testAs = List.copyOf( testBs );

这样做有以下优点:

这是一个简洁的一行代码 它不会产生警告 如果你的列表是用list .of()创建的，它不会复制!! 最重要的是:它做了正确的事情。

为什么这是对的?

如果你看一下List.copyOf()的源代码，你会发现它的工作原理如下:

如果您的列表是用list .of()创建的，那么它将执行强制转换并返回它，而不复制它。 否则，(例如，如果你的列表是一个ArrayList()，)它将创建一个副本并返回它。

如果List<TestB>是一个<TestB>的数组列表，那么必须创建一个数组列表的副本。如果您将ArrayList<TestB>转换为List<TestA>，则可能会无意中将一个TestA添加到List<TestA>中，这将导致原始ArrayList<TestB>在TestB中包含一个TestA，这是内存破坏:试图迭代原始ArrayList<TestB>中的所有TestB将抛出ClassCastException。

另一方面，如果List<TestB>是使用List.of()创建的，那么它是不可更改的(*1)，因此没有人会无意中向其添加一个TestA，因此可以将其强制转换为List<TestA>。

(*1) when these lists were first introduced they were called "immutable"; later they realized that it is wrong to call them immutable, because a collection cannot be immutable, since it cannot vouch for the immutability of the elements that it contains; so they changed the documentation to call them "unmodifiable" instead; however, "unmodifiable" already had a meaning before these lists were introduced, and it meant "an unmodifiable to you view of my list which I am still free to mutate as I please, and the mutations will be very visible to you". So, neither immutable or unmodifiable is correct. I like to call them "superficially immutable" in the sense that they are not deeply immutable, but that may ruffle some feathers, so I just called them "unchangeable" as a compromise.