|
|
|
Выделение памяти под массивы
|
|||
|---|---|---|---|
|
#18+
любой массив объектов в Java хранит ссылки на объекты (какими они ни были эти объекты). отсюда следует что все проинициализированные массивы будут занимать одинаковый объем памяти? (разумеется учитывается только массив ссылок на объекты а не сами проинициализированные объекты): Код: plaintext 1. 2. 3. 4. 5. сколько байт занимает одна ссылка? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 28.02.2006, 00:13 |
|
||
|
Выделение памяти под массивы
|
|||
|---|---|---|---|
|
#18+
на win32 думаю 4 ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 28.02.2006, 00:33 |
|
||
|
Выделение памяти под массивы
|
|||
|---|---|---|---|
|
#18+
unicornmirageлюбой массив объектов в Java хранит ссылки на объекты (какими они ни были эти объекты). отсюда следует что все проинициализированные массивы будут занимать одинаковый объем памяти? (разумеется учитывается только массив ссылок на объекты а не сами проинициализированные объекты): Код: plaintext 1. 2. 3. 4. 5. сколько байт занимает одна ссылка? Может зависит от разрядности платформы где установлена виртуальная машина? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 28.02.2006, 06:38 |
|
||
|
Выделение памяти под массивы
|
|||
|---|---|---|---|
|
#18+
спасибо за ответы. теперь отвечу почему я задал такой вопрос - например есть задача - где необходимо выделить своеобразный КЭШ для объектов произвольного типа. размер КЕШа заранее известен, также известен его максимально-возможный размер.. и в этом случае целесообразнее использовать заранее выделенный массив ссылок на объекты, чем использовать коллекции или списки, т.к. это будет работать гораздо быстрее? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 28.02.2006, 14:15 |
|
||
|
Выделение памяти под массивы
|
|||
|---|---|---|---|
|
#18+
ни думаю, что абгонит arrayList ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 28.02.2006, 15:00 |
|
||
|
Выделение памяти под массивы
|
|||
|---|---|---|---|
|
#18+
Объекты в Java идентифицируются хэш-кодом (т. е. "ссылка" о которой Вы говорите - это хэш код объекта) ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 28.02.2006, 15:57 |
|
||
|
Выделение памяти под массивы
|
|||
|---|---|---|---|
|
#18+
а хешкод - это число int, получается что 4 байта :) ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 28.02.2006, 22:28 |
|
||
|
Выделение памяти под массивы
|
|||
|---|---|---|---|
|
#18+
Объекты в Java НЕ идентифицируются хешкодом. Правило использования хешкода:если ссылки воззвращяют разный хешкод - они указывают на разные объекты. Все. Если один и тот же - никаких предположений не делается, делается попытка разрешить ссылку. Никто не запрещает везде возвращать например 1. Используется для оптимизации сравнения объектов, т.к. в случае сложной иерархии ссылок сравнение может быть дорогой операцией(надо пройти по всей цепочке, причем что еще хуже ссылки могут оказаться сетевыми или межпроцессными проксями). Идея полностью заимствована из CORBA образца 1993г. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 02.03.2006, 13:04 |
|
||
|
Выделение памяти под массивы
|
|||
|---|---|---|---|
|
#18+
unicornmirageспасибо за ответы. теперь отвечу почему я задал такой вопрос - например есть задача - где необходимо выделить своеобразный КЭШ для объектов произвольного типа. размер КЕШа заранее известен, также известен его максимально-возможный размер.. и в этом случае целесообразнее использовать заранее выделенный массив ссылок на объекты, чем использовать коллекции или списки, т.к. это будет работать гораздо быстрее? Для реализации кеша стоит посмотреть на слабые ссылки: Код: plaintext 1. Можно ничего не смотреть, а взять готовую реализацию из апачевского проекта commons-collections: Код: plaintext ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 02.03.2006, 17:39 |
|
||
|
|

start [/forum/topic.php?fid=59&msg=33576700&tid=2150037]: |
0ms |
get settings: |
7ms |
get forum list: |
9ms |
check forum access: |
2ms |
check topic access: |
2ms |
track hit: |
162ms |
get topic data: |
7ms |
get forum data: |
2ms |
get page messages: |
29ms |
get tp. blocked users: |
1ms |
| others: | 238ms |
| total: | 459ms |

| 0 / 0 |
