с точки зрения архитектуры это ужас и этого делать нельзя. Проблем может быть много. Вот цитата из Фаулер "Архитектура корпоративных программных приложений":

Вызов процедуры в пределах одного процесса про-текает чрезвычайно быстро. Вызов между двумя отдельными процессами, работающими на одном компьютере, обслуживается на несколько порядков медленнее. Активизируйте один из процессов на другой машине, и вы увеличите время обработки еще на пару по-рядков, в зависимости от сложности топологии конкретной сети.

Аналогично и с потоками будет замедление вызовов. Плюс как сказали выше тогда нужно блокировать объект, а это убивает концепцию асинхронности, так как пока 1 поток будет работать с объектом, другой будет ждать. Плюс если 1 поток сломает объект, корректно работать не смогут и остальные. Так что лучше для каждого потока создавать свой экземпляр. А вообще рекомендую прочесть Фаулер "Архитектура корпоративных программных приложений" 5ю главу про управление параллельными заданиями.Так что принимай решение сам, но это отнюдь не хорошая идея

Если ты лочишь доступ, то его на стороне где формируется запрос нужно будет обрабатывать - т.е. проверять залочен он или нет и что нужно делать с этим. Если ждать когда разлочится, то сколько ждать. В итоге в приложении у тебя будут сплошные задержки скорее всего.
Выше уже описали как стоит поступить.

не будет ни каких задержек. если лок держать всего на 1 чтение,или запись. Что имеется в виду, когда потоки прлетают в экземпляр, то не нужно ждать пока прочитат сразу все, а писать по 1 записи,или читать по 1 записи, за счет этого ни каких задержек в потоках не произойдет.
в таких случаях используют юнит оф ворк.

не будет ни каких задержек. если лок держать всего на 1 чтение,или запись. Что имеется в виду, когда потоки прлетают в экземпляр, то не нужно ждать пока прочитат сразу все, а писать по 1 записи,или читать по 1 записи, за счет этого ни каких задержек в потоках не произойдет.
в таких случаях используют юнит оф ворк.

Юнит оф ворк не совсем для этого используют же.

Unit of Work - излишнее усложнение. его используют для удобной работы с БД. В вопросе не сказано, что человек делает объект для работы с БД. Да и вообще есть мнение, что статики лучше избегать. Плюс если какой-то процесс изменит экземпляр, то следующий процесс уже не сможет с ним нормально работать.

мы уже поднимали вопрос по статикам. я ради интереса ходил на сайт стейковерфлоу, и там люди советуют ставить этот static/ ссылку я кидал

я этого не застал(

Егор Бугаенко "Elegant objects" тут сказано почему не стоит юзать статику

мне нужна помощь гения @chelio0s