Многопоточность Java и Безопасная Публикация
Вы должны просто выбрать результаты для каждой страницы / номера строки и просто рассчитать, какие результаты вам нужны, например:
SELECT *
FROM ( SELECT ROW_NUMBER() OVER ( ORDER BY OrderDate ) AS RowNum, *
FROM Orders
WHERE OrderDate >= '1980-01-01'
) AS RowConstrainedResult
WHERE RowNum >= 1
AND RowNum < 20
ORDER BY RowNum
Этот SQL является копией ответа mdb для разбивки на страницы, что вам нужно: Как лучше всего разбивать результаты на страницы в SQL Server
6 ответов
Proportionally, it's probably fair to say that very few programmers sufficiently understand synchronization and concurrency. Who knows how many server applications there are out there right now managing financial transactions, medical records, police records, telephony etc etc that are full of synchronization bugs and essentially work by accident, or very very occasionally fail (never heard of anybody get a phantom phone call added to their telephone bill?) for reasons that are never really looked into or gotten to the bottom of.
Object publication is a particular problem because it's often overlooked, and it's a place where it's quite reasonable for compilers to make optimisations that could result in unexpected behaviour if you don't know about it: in the JIT-compiled code, storing a pointer, then incrementing it and storing the data is a very reasonable thing to do. You might think it's "evil", but at a low level, it's really how you'd expect the JVM spec to be. (Incidentally, I've heard of real-life programs running in JRockit suffering from this problem-- it's not purely theoretical.)
If you know that your application has synchronization bugs but isn't misbehaving in your current JVM on your current hardware, then (a) congratulations; and (b), now is the time to start "walking calmly towards the fire exit", fixing your code and educating your programmers before you need to upgrade too many components.
"это действительно реальная проблема?" 1262 Да, конечно. Даже самое тривиальное веб-приложение должно сталкиваться с проблемами, связанными с параллелизмом. К сервлетам обращаются, например, из нескольких потоков.
Другая проблема заключается в том, что многопоточность и параллелизм очень трудно правильно обрабатывать. Это почти слишком сложно. Вот почему мы наблюдаем появление таких тенденций, как транзакционная память, и таких языков, как Clojure, которые, как мы надеемся, облегчают параллелизм. Но у нас есть пути, прежде чем они станут основным потоком. Таким образом, мы должны делать все возможное с тем, что имеем. Чтение JCiP - очень хорошее начало.
Я бы сказал, что очень немногие программисты уходят от этой проблемы. Когда вы видели последний пример кода, в котором использовалось ключевое слово volatile? Тем не менее, большинство других упомянутых условий - я просто воспринимал как должное как лучшие практики.
Если разработчик полностью пренебрегает этими условиями, они быстро столкнутся с многопоточными ошибками.
Во-первых, «безопасная публикация» на самом деле не является идиомой (ИМО). Это происходит из языка.
Были случаи проблем с небезопасной публикацией, например с использованием NIO.
Большая часть кода Java написана очень плохо. Потоковый код, очевидно, сложнее, чем обычный бизнес-код.
Дело не в том, чтобы быть «злым». Это является реальной проблемой и станет намного более очевидным с ростом многоядерных архитектур в ближайшие годы. Я видел очень реальные производственные ошибки из-за неправильной синхронизации. И чтобы ответить на ваш другой вопрос, я бы сказал, что очень немногие программисты знают об этой проблеме, даже среди «хороших» разработчиков.
Мой опыт (краткосрочные и консалтинговые в самых разных средах) Большинство приложений, которые я видел), согласны с этой интуицией - я никогда не видел, чтобы целая система была четко спроектирована для тщательного управления этой проблемой (ну, я также почти никогда не видел, чтобы вся система была четко спроектирована). Я работал с очень, очень немногими разработчиками с хорошим знанием проблем потоков.
Особенно с веб-приложениями, вы часто можете сойти с рук или, по крайней мере, сойти с рук. Если у вас есть экземпляры на основе Spring, управляющие созданием объектов и сервлетами без сохранения состояния, вы часто можете притворяться, что такой вещи, как синхронизация, не существует, и именно в этом случае заканчивается множество приложений. В конце концов кто-то начинает помещать какое-то общее состояние туда, где оно не принадлежит, и через 3 месяца кто-то замечает некоторые странные периодические ошибки. Это часто "достаточно хорошо" для многих людей (если вы не пишете банковские транзакции).
Сколько разработчиков Java знают об этой проблеме? Трудно сказать, так как это сильно зависит от того, где вы работаете.