Выделение объекта Java наверху
Я нашел способ добиться этого с помощью 1 запроса:
GET /{userId}?fields=
posts.as(like){reactions.type(LIKE).limit(0).summary(true)},
posts.as(love){reactions.type(LOVE).limit(0).summary(true)},
posts.as(wow){reactions.type(WOW).limit(0).summary(true)},
posts.as(haha){reactions.type(HAHA).limit(0).summary(true)},
posts.as(sad){reactions.type(SAD).limit(0).summary(true)},
posts.as(angry){reactions.type(ANGRY).limit(0).summary(true)},
posts.as(thankful){reactions.type(THANKFUL).limit(0).summary(true)}
Таким образом вы получите 7 списков сообщений (по одному на каждую реакцию). Пример:
{
"like": {
"data": [<list of posts>]
},
"love": {
"data": [<list of posts>]
},
"wow": {
"data": [<list of posts>]
},
"haha": {
"data": [<list of posts>]
},
"sad": {
"data": [<list of posts>]
},
"angry": {
"data": [<list of posts>]
},
"thankful": {
"data": [<list of posts>]
},
"paging": {
"previous": "...",
"next": "..."
},
"id": "<userId>"
}
6 ответов
В эти дни создание объекта довольно блин быстро, и понятие пулинга объектов является довольно устаревшим (по крайней мере в целом; организация пула подключений, конечно, все еще допустима).
Избегайте преждевременной оптимизации. Создайте свои узлы при необходимости в них при выполнении копий, и затем видеть, становится ли это непомерно медленным. Если так, затем изучите некоторые методы для ускорения его. Но если Вы уже не знаете, что то, что Вы имеете, не достаточно быстро, я не пошел бы, представив всю сложность, в которой Вы испытываете необходимость для получения движения объединения.
Я очень не хочу дать неответ, но я думаю, что единственный категорический способ ответить на вопрос производительности как это мог бы состоять в том, чтобы Вы кодировали оба подхода, сравните этих двух и сравните результаты.
Я не уверен, можно ли постараться не явно синхронизировать определенные методы, чтобы удостовериться, что все ориентировано на многопотоковое исполнение.
Один конкретный случай необходимо синхронизировать одну сторону или другое предоставление доступа к недавно созданному узлу, для других потоков как иначе, Вы рискуете VM/CPU переупорядочение записей полей мимо записи ссылки на общий узел, подвергая сторону созданный объект.
Попытайтесь думать в более высоком уровне. У Вас есть НЕИЗМЕННОЕ дерево (который является в основном рядом узлов, указывающих на его детей). Вы хотите вставить узел в него. Затем нет никакого выхода: необходимо создать новое ЦЕЛОЕ дерево.
Если бы Вы принимаете решение реализовать дерево как ряд узлов, указывающих на детей, то необходимо было бы создать новые узлы вдоль пути измененного узла к корню. Другие имеют то же значение как прежде и обычно совместно используются. Таким образом, необходимо создать частичное новое дерево, которое обычно означало бы (глубина отредактированного узла) родительские узлы.
Если можно справиться с менее прямой реализацией, необходимо смочь сойти с рук только создание частей узлов, с помощью методов, подобных описанным в Чисто Функциональных Структурах данных для или сокращения средней стоимости создания, или можно обойти его с помощью полуфункциональных подходов (таких как создание итератора, который переносит существующий итератор, но возвращает новый узел вместо старого, вместе с механизмом для восстановления таких патчей в структуре со временем). API стиля XPath мог бы быть лучше, чем API DOM в этом случае - он мог бы Вы отделять узлы от дерева немного больше и рассматривать видоизмененное дерево более разумно.
Когда Вы вытаскиваете объект из пула, разве Вы не должны будете вызывать метод set для соединения дочерних элементов?
Каждый узел не должен быть неизменным внутренне к пакету, только к стоящему исходящим образом интерфейсу. node.addChild() был бы неизменная функция с общедоступной видимостью и возвратила бы Документ, тогда как node.addChildInternal() был бы быть нормальной, изменяемой функцией с видимостью пакета. Но так как это является внутренним к пакету, это можно только назвать как потомок addChild() и структура в целом, как гарантируют, будет ориентирована на многопотоковое исполнение (если я синхронизирую доступ к пулу объектов). Вы видите дефект в этом...? Если так, скажите мне!
Я думаю, что использование неизменных узлов, вероятно, не собирается давать Вам вид потокобезопасности, в которой Вы нуждаетесь во-первых. Что происходит, если 1 поток выполняет итерации по узлам (поиск или что-то), в то время как другой поток добавляет/удаляет узлы?
Дерево в целом будет неизменно. Скажите, что у меня есть Thread1 и Thread2 и дерево dom1. Thread1 запускает операцию чтения на dom1, в то время как, одновременно, Thread2 запускает операцию записи на dom1. Однако все изменения, которыми Thread2 составляет завещание на самом деле быть сделанным к новому объекту, dom2, и dom1, будут неизменны. Это верно, что значения, считанные Thread1, будут (несколько микросекунд) устаревшие, но это не откажет на исключении IndexOutOfBounds или NullPointer, или что-то как он было бы, если это читало изменяемый объект, который писался в. Затем Thread2 может запустить событие, содержащее dom2 к Thread1 так, чтобы это могло сделать свое чтение снова и обновить его результаты при необходимости.
Править: разъясненный
Я немного смущен тем, что Вы пытаетесь сделать во-первых. Вы хотите, чтобы все узлы были неизменны, И Вы хотите объединить их? Разве эти 2 идеи не являются взаимоисключающими? Когда Вы вытаскиваете объект из пула, разве Вы не должны будете вызывать метод set для соединения дочерних элементов?
Я думаю, что использование неизменных узлов, вероятно, не собирается давать Вам вид потокобезопасности, в которой Вы нуждаетесь во-первых. Что происходит, если 1 поток выполняет итерации по узлам (поиск или что-то), в то время как другой поток добавляет/удаляет узлы? Не будут результаты поиска быть недопустимыми? Я не уверен, можно ли постараться не явно синхронизировать определенные методы, чтобы удостовериться, что все ориентировано на многопотоковое исполнение.
Я думаю, что @Outlaw имеет точку. Структура дерева DOM находится в узлах самого, имея узел, указывающий на его детей. Для изменения структуры дерева, необходимо изменить узел, таким образом, Вам нельзя было объединить его, необходимо создать новый.
Попытайтесь думать в более высоком уровне. У Вас есть НЕИЗМЕННОЕ дерево (который является в основном рядом узлов, указывающих на его детей). Вы хотите вставить узел в него. Затем нет никакого выхода: необходимо создать новое ЦЕЛОЕ дерево.
Да, неизменное дерево ориентировано на многопотоковое исполнение, но оно повлияет на производительность. Создание объекта может быть быстрым, но не быстрее затем НИКАКОЕ создание объекта.:)