StackOverflowError при сериализации объекта в Java
Если вы посмотрите на сигнатуру Comparator.comparing, то общий параметр U extends Comparable<? super U>
public static <T, U extends Comparable<? super U>> Comparator<T> comparing(
Function<? super T, ? extends U> keyExtractor)
, который означает, что все, что возвращает getElement, должно быть Comparable.
Примечание: здесь тип T - это вершина, а U - это тип того, что возвращает getElement.
Это можно решить, сделав T extends Comparable<? super T> в классе Vertex.
class Vertex<T extends Comparable<? super T>> {...}
6 ответов
Интересное сообщение от Chen:
При отладке переполнения стека Вы хотите сфокусироваться на повторяющейся рекурсивной части
В Вашем случае:
at java.io.ObjectOutputStream.writeOrdinaryObject(ObjectOutputStream.java:1392)
at java.io.ObjectOutputStream.writeObject0(ObjectOutputStream.java:1150)
at java.io.ObjectOutputStream.defaultWriteFields(ObjectOutputStream.java:1509)
at java.io.ObjectOutputStream.writeSerialData(ObjectOutputStream.java:1474)
at java.io.ObjectOutputStream.writeOrdinaryObject(ObjectOutputStream.java:1392)
at java.io.ObjectOutputStream.writeObject0(ObjectOutputStream.java:1150)
at java.io.ObjectOutputStream.writeObject(ObjectOutputStream.java:326)
at java.util.ArrayList.writeObject(ArrayList.java:570)
at sun.reflect.GeneratedMethodAccessor6.invoke(Unknown Source)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
at java.lang.reflect.Method.invoke(Method.java:597)
at java.io.ObjectStreamClass.invokeWriteObject(ObjectStreamClass.java:945)
at java.io.ObjectOutputStream.writeSerialData(ObjectOutputStream.java:1461)
Если Вы отправитесь на охоту через свою базу данных отслеживания дефекта, пытающуюся видеть, является ли это известной проблемой или нет, поиск главных функций на стеке вряд ли найдет что-либо интересным. Поэтому переполнения стека имеют тенденцию происходить в случайной точке в рекурсии; каждое переполнение стека выглядит поверхностно отличающимся от любого, даже если они - то же переполнение стека.
После того как Вы заканчиваете начальную суматоху, отслеживание стека успокаивается в хороший шаблон повторения, состоящий из тех же функций x много раз.
Идентификация запуска повторяющегося шаблона не важна, потому что начальная точка будет отличаться для каждого катастрофического отказа, таким же образом что точное примечание, которое превышает Ваш певчий диапазон, варьируется от катастрофического отказа до катастрофического отказа.После того как Вы определили повторяющуюся часть, выберите функцию от нее, которая несколько необычна, и ищите ее в своей дефектной базе данных.
Например, значение по умолчанию ArrayList сериализация.
Здесь Ваш GrahPanel отсылает a Simulation который относится к Graph, с потенциально долго ArrayList из датчика и края...
Сериализация Java ведет учет каждого объекта, записанного в поток. Если с тем же объектом встречаются во второй раз, только ссылка на него записана в поток и не вторую копию объекта; таким образом, циклические ссылки не являются проблемой здесь.
Но сериализация уязвима для переполнения стека для определенных видов структур; например, длинный связанный список без специального writeObject () методы будет сериализирован путем рекурсивной записи каждой ссылки. Если у Вас есть 100,000 ссылки, Вы собираетесь попытаться использовать 100 000 стековых фреймов и довольно вероятно перестать работать с StackOverflowError.
Возможно определить writeObject () метод для такого класса списка, который, когда первая ссылка сериализируется, просто обходит список и сериализирует каждую ссылку многократно; это будет препятствовать тому, чтобы рекурсивный механизм по умолчанию использовался.
Необходимо рассмотреть перереализацию writeObject / readObject методы Вашего класса Моделирования для сериализации только соответствующих данных (а не вся структура содержащего в нем объекта по умолчанию) или метки переходного процесса Ваш, чтобы не быть сериализованными объектами. Можно также использовать Externalizable интерфейс в случае необходимости.
BTW, можно хотеть прочитать эту интересную статью для начала.
У Вас есть некоторый глубоко вложенный ArrayLists.
Я думаю, возможно, что это просто идет глубина сначала, и это означает, что идет для нижнего Датчика, который слишком глубок.
Возможно, Вы могли создать пользовательскую структуру с Датчиками, запускающимися с нижнего Датчика?
Или возможно необходимо ли будет обеспечить собственную сериализацию для обработки его? http://java.sun.com/developer/technicalArticles/Programming/serialization/
Необходимо создать контейнерный класс для объектов, которые Вы хотите хранить. Я не снабдил бы полное этот объект всей логикой внутри.
Сохраните первое поле полем для нахождения элемента, который является к большому для хранения его тот путь. Чем помещенный точка останова в методе и смотрят на полевой элемент. Элемент содержит ссылки, которые связываются друг с другом?
И после Вас сделанный все, что просто использует XStream вместо этого, если Вы только хотите сохранить в файл.